Bandwidth management, aggregation and internet protocol flow mobility across multiple-access technologies

ABSTRACT

Systems, apparatuses and methods for bandwidth management, aggregation and internet protocol (“IP”) flow mobility (“IFOM”) across multiple-access technologies are provided. Included is a method that includes selecting, from a packet data network (“PDN”) connection formed through a plurality of access systems communicatively coupled with a wireless transmit and/or receive unit (“WTRU”), an access system over which to transport a flow of internet protocol (“IP”) traffic to and/or from the WTRU. The method may also include sending, to the WTRU, a request to associate the flow of IP traffic with the selected access system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/820,724, filed 12 Feb. 2014, which is a §371 of International Appln.No. PCT/US2011/50577, filed 6 Sep. 2011, which claims the benefit ofProvisional (“Prov.”) Pat. Appln. Ser. Nos. (i) 61/380,527, filed 7 Sep.2010, (ii) 61/475,023, filed 13 Apr. 2011, and (iii) 61/514,895, filed 3Aug. 2011.

BACKGROUND

1. Field

This application is related to wireless communications.

2. Related Art

Mobile operators may employ any of macro cells, femtocells, microcells,wireless local area networks (“WLAN”), and the like to improve coverageand capacity of communications for their subscribers, especiallyindoors. As a function of the improved coverage and capacity, thesubscribers may experience better voice quality/data rates and batterylife of mobile devices over connecting to macro cells alone. Dependingon the carrier, the subscribers may also be offered more attractivetariffs, e.g., discounted calls from home.

SUMMARY

Systems, apparatuses and methods for bandwidth management, aggregationand internet protocol (“IP”) flow mobility (“IFOM”) acrossmultiple-access technologies are provided. Included among systems,apparatuses and methods is a method that includes selecting, from apacket data network (“PDN”) connection formed through a plurality ofaccess systems of a network communicatively coupled with a wirelesstransmit and/or receive unit (“WTRU”), an access system over which totransport a flow of internet protocol (“IP”) traffic to and/or from theWTRU. The method may also include sending, to the WTRU, a request toassociate the flow of IP traffic with the selected access system.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the detailed descriptionbelow, given by way of example in conjunction with drawings appendedhereto. Figures in such drawings, like the detailed description, areexamples. As such, the Figures and the detailed description are not tobe considered limiting, and other equally effective examples arepossible and likely. Furthermore, like reference numerals in the Figuresindicate like elements, and wherein:

FIG. 1 is a block diagram illustrating an example of a communicationssystem in which one or more disclosed embodiments may be implementedand/or carried out;

FIG. 2 is a flow diagram illustrating an example of a flow forperforming (“IP”) flow mobility (“IFOM”) across multiple accesstechnologies;

FIG. 3 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 4 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 5 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 6 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 7 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 8 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 9 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 10 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 11 is a flow diagram illustrating an example of a flow forperforming IFOM across multiple access technologies;

FIG. 12A is a block diagram illustrating an example of a communicationssystem in which one or more disclosed embodiments may be implementedand/or carried out;

FIG. 12B is a block diagram illustrating an example wirelesstransmit/receive unit (WTRU) that may be used within the communicationssystem illustrated in FIG. 12A;

FIG. 12C is a block diagram illustrating an example radio access network(“RAN”) and an example core network (“CN”) that may be used within thecommunications system illustrated in FIG. 12A;

FIG. 12D is a block diagram illustrating an example of a RAN and aexample of a CN;

FIG. 12E is a block diagram illustrating an example of a RAN and aexample of a CN;

FIG. 13 is a block diagram illustrating an example of a communicationssystem in which one or more disclosed embodiments may be implementedand/or carried out;

FIGS. 14A-14B are block diagrams illustrating an example of acommunication system in which one or more disclosed embodiments may beimplemented and/or carried out;

FIG. 15A is a block diagram illustrating protocols that may be used toprovide any og bandwidth management (“BMW”), bandwidth aggregation(“BWA”) and IFOM in a communications system;

FIG. 15B is a chart illustrating an example of a flow table forperforming IFOM across multiple access technologies;

FIG. 16 is a message flow diagram illustrating an example of a processfor establishing a multiple access PDN connection with support for IFOM;

FIG. 17 is a message-flow diagram illustrating an example of a processfor performing WTRU-initiated IFOM;

FIG. 18 is a message flow diagram illustrating an example of a processfor performing network-initiated IFOM over multiple access technologies;

FIG. 19 is a message flow diagram illustrating an example of a processfor performing network-initiated IFOM over multiple access technologies;

FIG. 20 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 21 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 22 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 23 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 24 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 25 is a message flow diagram illustrating an example of a processfor performing IFOM over multiple access technologies;

FIG. 26 is a block diagram illustrating an example of a communicationssystem for performing BWM;

FIGS. 27A-27K are block diagrams illustrating examples of communicationssystems in which one or more disclosed embodiments may be implementedand/or carried out;

FIG. 28 is a block diagram illustrating protocols for providing any ofBMW, BWA and/or IFOM in a communications system; and

FIG. 29 is a flow diagram illustrating an example of a process forperforming any of BMW, BWA and/or IFOM in a communications system.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth to provide a thorough understanding of embodiments and/or examplesdisclosed herein. However, it will be understood that such embodimentsand examples may be practiced without some or all of the specificdetails set forth herein. In other instances, well-known methods,procedures, components and circuits have not been described in detail,so as not to obscure the following description. Further, embodiments andexamples not specifically described herein may be practiced in lieu of,or in combination with, the embodiments and other examples disclosedherein.

FIG. 1 is a block diagram illustrating an example of a communicationssystem 100 in which one or more disclosed embodiments may be implementedand/or carried out. The communications system 100, for example, may besuitable for implementing and/or carrying out any of bandwidthmanagement, bandwidth aggregation and internet protocol (“IP”) flowmobility (“IFOM”) across multiple access technologies. The IFOM may bebased on IP-level protocols. These IP-level protocols may include, forexample, general-packet-radio service (“GPRS”) tunneling protocol(“GTP”), and/or protocols based and/or built on Mobile-IP (“MIP”), suchas, for example, dual-stack MIP (“DSMIP”) and proxy MIP (“PMIP”).

In general, the communications system 100 defines an architecture thatsupports a plurality of access systems over which multiple wirelessusers may access and/or exchange (e.g., send and/or receive) content,such as voice, data, video, messaging, broadcast, etc. The architecturealso supports having two or more of the access systems use and/or beconfigured in accordance with multiple (i.e., different) accesstechnologies. This way, the communications system 100 may service thewireless users capable of using a single access technology, and thewireless users capable of using two or more of the multiple accesstechnologies.

The communications system 100 may enable the wireless users to accessthe content through sharing and/or distribution of system resources,including, for example, wireless bandwidth. The communications system100, for example, may employ one or more channel access methods, such ascode division multiple access (CDMA), time division multiple access(TDMA), frequency division multiple access (FDMA), orthogonal FDMA(OFDMA), single-carrier FDMA (SC-FDMA), and the like.

The communications system 100 may include a wireless transmit and/orreceive unit (“WTRU”) 102 and a network 103. The network 103 may includea plurality of access systems 105 _(1-n) communicatively coupled with anetwork entity 107. The network 103 may also include one or moreadditional access systems and/or other network elements, nodes,entities, etc.; none of which are shown in FIG. 1 for simplicity ofexposition. Details of example architectures of various networks, any ofwhich may be representative of the network 103, are described herein.

The network entity 107 may be configured and/or adapted (collectively“configured”) to manage one or more packet data network (“PDN”)connections carried over the access systems 105 _(1-n) (hereinafter“multi-access connection manager 107”). In general, the WTRU 102 may beany type of device configured to operate and/or communicate overwireless or wireless and wired media. The WTRU 102, for example, may beconfigured to exchange signals over the wireless and/or wired media, andmay include user equipment (“UE”), a mobile station, a fixed or mobilesubscriber unit, a pager, a cellular telephone, a personal digitalassistant (PDA), a Smartphone, a laptop, a netbook, a personal computer,a wireless sensor, consumer electronics, and the like. The WTRU 102 mayalso include a number of elements to facilitate its operation; none ofwhich, however, are shown in FIG. 1 for simplicity of exposition.Details of example architectures of various WTRUs, any of which may berepresentative of the WTRU 102, are described herein.

Each of the access systems 105 _(1-n) may be configured in accordancewith the same access technology. Alternatively, some or all of theaccess systems 105 _(1-n) may be configured in accordance with differentaccess technologies. For example, the first, second and third accesssystems 105 ₁, 105 ₂ and 105 ₃ may be configured in accordance withdifferent access technologies; and the remaining access systems 105_(4-n) may be configured in accordance the same access technology (e.g.,the same access technology as access system 105 ₂). Examples of themultiple access technologies may include an access technologies asspecified in a release promulgated by the third generation partnershipproject (“3GPP”), IEEE 802.11, IEEE 802.16, other non-3GPP cellularaccess technologies and the like.

Each of the access systems 105 _(1-n) may provide any of ingress intoand egress from the network 103 for communications exchanged between,for example, the WTRU 102 and a network 111 external to thecommunications system 100. The network (“external network”) 111 mayinclude and/or be one or more of various types of communicationnetworks, including, for example, any of a core network, a mobile corenetwork, an internet, a service-provider network and other like-typenetwork.

To facilitate communication over the access systems 105 _(1-n), the WTRU102 and the access systems 105 _(1-n) may establish respective airinterfaces 116 _(1-n) (e.g., wireless links) in accordance with therespective access technologies. The WTRU 102 may also establish PDNconnections and/or IP connectivity with various nodes (e.g., packet datagateways (“PDGs”)) of the network 103 and/or with the network 110 overthe access systems 105 _(1-n) (individually or combined). The PDNconnections and/or IP connectivity may be established over interfacesdefined in accordance with the access technologies of the correspondingaccess systems 105 _(1-n).

The WTRU 102 may also establish connectivity with the multi-accessconnection manager 107 via one or more of the access systems 105 _(1-n).Such connectivity may be established via any previously-established PDNconnection or IP connection, for example. The WTRU 102 and multi-accessconnection manager 107 may use also use an existing tunnel or,alternatively, establish a tunnel to obtain connectivity and/or toexchange communications.

The WTRU 102 and multi-access connection manager 107 may, for example,exchange communications (e.g., signaling messages) to facilitate and/ormanage IP traffic carried over the PDN connections. The WTRU 102 andmulti-access connection manager 107 may, for example, exchange messagesto facilitate forming and form a single PDN connection from various PDNand IP connections carried over the access systems 1051. These messagesmay include one or more messages for binding together or otherwisecombining (i) multiple PDN connections, (ii) one or more PDN connectionswith one or more IP connections and/or (iii) multiple IP connections foruse as the single PDN connection (hereinafter “multi-access PDNconnection”).

The WTRU 102 and multi-access connection manager 107 may also exchangemessages and to facilitate and/or control any of routing, forwardingand/or other transport of one or more flows of IP traffic (“IP flows”)over the access systems 105 _(1-n) of the multi-access PDN connection.In addition, the WTRU 102 and multi-access connection manager 107 maymaintain in respective data structures (e.g., tables) informationidentifying the multi-access PDN connection, the PDN and IP connectionsbound to the multi-access PDN connection, and the IP flows associatedwith the multi-access PDN connection.

FIGS. 2-11 are flow diagrams illustrating respective examples ofprocesses 200-1100 for performing IFOM across multiple accesstechnologies. Each of the processes 200-1100 is described with referenceto the communications system 100 of FIG. 1. The processes 200-1100 maybe carried out using other architectures, as well. Where applicable,reference may be made between and/or among the processes 200-1100 orelements thereof.

Referring now to FIG. 2, a flow diagram illustrating an example of aprocess 200 for performing IFOM across multiple access technologies isshown. The WTRU 102 may connect to and establish a PDN connectionthrough the access system 1051 (“initial PDN connection”), as shown inblock 202. During establishment of the initial PDN connection,information relating to the WTRU 102 in connection with the initial PDNconnection may be assigned to and/or associated with the WTRU 102(“initial PDN-connection information”). The initial PDN-connectioninformation may include, for example, an IP address assigned to the WTRU102 (“anchor address”).

As shown in block 204, the WTRU 102 may register with the multi-accessconnection manager 107 in connection with the initial PDN connection.The WTRU 102 may initiate registration by sending to the multi-accessconnection manager 107 a message configured to instruct the multi-accessconnection manager 107 to register the WTRU 102 in connection with thePDN connection. This message (“registration message”) may include theinitial PDN-connection information, or alternatively, a portion of suchinitial PDN-connection information, such as, for example, the anchoraddress.

After receipt, the multi-access connection manager 107 may extract theinitial PDN-connection information from the registration message. Themulti-access connection manager 107 may then populate some or all of theinitial PDN-connection information into the connection manager datastructure of multi-access connection manager 107 (hereinafter“connection manager data structure”).

Thereafter, the multi-access connection manager 107 may send to the WTRU102 a message to acknowledge the registration message (“registration-ackmessage”). The registration-ack message may include an indication thatthe multi-access connection manager 107 successfully registered the WTRU102. Responsive to the successful registration, the WTRU 102 maypopulate the WTRU data structure with some or all of the initialPDN-connection information. The initial PDN-connection informationpopulated in the WTRU data structure may be the same as or differentfrom the initial PDN-connection information populated into theconnection manager data structure.

As shown in block 206, the WTRU 102 may connect to, and establish an IPconnectivity over with, the access system 105 ₂ (hereinafter“second-access connectivity”) During establishment of the second-accessconnectivity, information relating to the WTRU 102 in connection withthe second-access connectivity may be assigned and/or associated withthe WTRU 102 (“second-access-connectivity information”). Thesecond-access-connectivity information may include, for example, an IPaddress assigned to the WTRU 102 (“routing address”).

After connecting to the access system 105 ₂, the WTRU 102 may instructthe multi-access connection manager 107 to add or join the access system105 ₂ to initial PDN connection, as shown in block 208. The WTRU 102 mayinstruct the multi-access connection manager 107 by sending a messagewith instructions to bind the second-access connectivity to the initialPDN connection. This message (“binding message”) may include thesecond-access-connectivity information. Alternatively, the bindingmessage may include a portion of the second-access-connectivityinformation, such as, for example, the routing address. After receipt ofthe binding message, the multi-access connection manager 107 maypopulate second-access-connectivity information into the network datastructure in association with the initial PDN-connection information.

The multi-access connection manager 107 may send to the WTRU 102 amessage to acknowledge the binding message (“binding-ack message”). Thebinding-ack message may include an indication for notifying the WTRU 102that the multi-access connection manager 107 successfully added theaccess system 105 ₂ to the multi-access PDN connection. Responsive tosuch notification, the WTRU 102 may populate thesecond-access-connectivity information into the WTRU data structure inassociation with the initial PDN-connection information. Thesecond-access-connectivity information populated into the WTRU datastructure may be the same as or different from thesecond-access-connectivity information populated into the connectionmanager data structure.

Although not shown in FIG. 2, one or more of the access systems 105_(3-n) may be added to the multiple-access PDN connection by repeatingblocks 206-208 for each of the access systems 105 _(3-n) to be added.Alternatively, any of the access systems 105 _(3-n) may be added and/orjoined to the initial PDN connection in lieu of the access system 105 ₂.

FIG. 3 is a flow diagram illustrating an example of a process 300 forperforming IFOM across multiple access technologies. The process 300 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2. The process 300 may be performedafter a multi-access PDN connection is established in other ways, aswell. The process 300 may be used to facilitate assignment of and/orassign a given IP flow to a particular access system.

As shown in block 302, the multi-access connection manager 107 mayselect the access network 105 ₁ to provide transport for a given IPflow. The multi-access connection manager 107 may select the accessnetwork 105 ₁, for example, responsive to an event for triggering achange in assignment of the given IP flow (“flow-updating event”). Theflow-updating event may be configured to occur at any of a predefinedtime or frequency (e.g., at certain times of a day, every few hours, atscheduled times for maintenance, etc.). Alternatively, the flow-updatingevent may be triggered responsive to one or more conditions of thecommunications system 100. Such conditions may include congestion and/orlimited connectivity occurring (or anticipated to occur) in and/or inassociation with the communications system 107, including, any of thenetworks 103, 110; PDN connections; links associated with IPconnectivity; access systems 105 _(1-n); and air interfaces 116 _(1-n).The flow-updating event may be based on one or more policies of thenetwork 103 or the communications system 100, as well.

After selecting the access network 105 ₁, the multi-access connectionmanager 107 may send to the WTRU 102 a request to associate the given IPflow with the access network 105 ₁, as shown in block 304. Themulti-access connection manager 107 may send the request using asignaling message configured for requesting an update to a previousbound connection (e.g., a binding update (“BU”) message). This BUmessage may include the initial PDN-connection information andinformation associated with the given IP flow (“IP-flow information”).The IP-flow information may include an identifier assigned to the IPflow (“FID”) and a routing filter. The routing filter may be configuredto facilitate filtering of the given IP flow from other traffic and/orrouting of the given IP flow. The routing filter may include adescription and/or a characterization of the given IP flow. For example,the routing filter may include a traffic selector or any other n-tuplecontaining a source IP, destination IP, source port, destination port,transport protocol and any other fields in IP and higher layer headers(e.g. media type).

In one embodiment, as shown in block 306, the multi-access connectionmanager 107 may receive from the WTRU 102 an acknowledgement of therequest. The acknowledgement may be carried in a signaling messageconfigured for acknowledging a binding update (e.g., a bindingacknowledging (“BA”) message). The BA message may include the initialPDN-connection information and the IP-flow information. Such informationmay be used to confirm the binding update.

In one embodiment, as shown in block 308, the multi-access connectionmanager 107 may obtain an acceptance of the request. The multi-accessconnection manager 107 may obtain the acceptance of the request in anumber of ways. For instance, the multi-access connection manager 107may infer the acceptance from (i) receipt of the BA message, (ii) notreceiving a response to the BU message or (II) not receiving a rejectionof the request from the WTRU 102. Alternatively, the BA message mayinclude an indication of the acceptance of the request.

In one embodiment, as shown in block 310, the multi-access connectionmanager 107 and the WTRU 102 may associate the given IP flow with theaccess network 105 ₁, responsive to acceptance of the request. Tofacilitate making the association, the WTRU 102 may extract the IP-flowinformation from the BU message. Thereafter, the WTRU 102 may associatethe given IP flow with the access network 105 ₁, for example, bypopulating the IP-flow information into the WTRU data structure inassociation with the initial PDN-connection information. Similarly, themulti-access connection manager 107 may associate the given IP flow withthe access network 105 ₁ by populating the IP-flow information into theconnection manager data structure in association with the initialPDN-connection information.

Although not shown in FIG. 3, the multi-access connection manager 107may select the access system 105 ₂ or any of the other the accesssystems 105 _(3-n) (if added to the multiple-access PDN connection) fortransport of the given IP flow.

FIG. 4 is a flow diagram illustrating an example of a process 400 forperforming IFOM across multiple access technologies. The process 400 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2. The process 400 may be performedafter a multi-access PDN connection is established in other ways, aswell. The process 400 may be used to make a request to reassign (e.g.,move) and/or to reassign the IP flow from one access system to another.

As shown in block 402, the multi-access connection manager 107 mayselect the access system 105 ₂ of the multi-access PDN connection fortransport of the IP flow to and/or from the WTRU 102. Selection of theaccess system 105 ₂ by multi-access connection manager 107 may beresponsive to a flow-updating event.

After selecting the access system 105 ₂, the multi-access connectionmanager 107 may send to the WTRU 102 a request to reassign the IP flowto the access system 105 ₂, as shown in block 404. The request(“reassignment request”) may include requests to (i) associate the IPflow to access system 105 ₂, and (ii) de-associate the IP flow from theaccess system 105 ₁. The multi-access connection manager 107 may use aBU message, for example, to send the reassignment request to the WTRU102. The BU message may include the second-access-connectivityinformation and the IP-flow information.

In one embodiment, the multi-access connection manager 107 may receivefrom the WTRU 102 an acknowledgement of the reassignment request, asshown in block 406. This acknowledgement may be carried in a BA messagesent from the WTRU 102. The BA message may include thesecond-access-connectivity information and the IP-flow information,which may be used to signal to the multi-access connection manager 107 aconfirmation of the binding update.

In one embodiment, the multi-access connection manager 107 may obtain anacceptance of the move request, as shown in block 408. The multi-accessconnection manager 107 may, for example, infer the acceptance from (i)receipt of the BA message, (ii) not receiving a response to the BUmessage or (iii) not receiving a rejection of the request from the WTRU102. Alternatively, the BA message may include an indication of theacceptance of the request.

In one embodiment, the multi-access connection manager 107 and the WTRU102 may associate the IP flow with the access network 105 ₂ andde-associate the IP flow with the access network 105 ₁, responsive toacceptance of the request, as shown in optional block 410. To facilitatemaking the association and de-association, the WTRU 102 may extract theIP-flow information from the BU message. Thereafter, the WTRU 102 mayassociate the IP flow with the access network 105 ₂ and de-associate theIP flow with the access network 105 ₁, for example, by populating theIP-flow information into the WTRU data structure in association with thesecond-access connection information. Similarly, the multi-accessconnection manager 107 may associate the IP flow with the access network105 ₂ and de-associate the IP flow with the access network 105 ₁ bypopulating the IP-flow information into the connection manager datastructure in association with the second-access connection information.

Although not shown in FIG. 4, the multi-access connection manager 107may select any of the other the access systems 105 _(3-n) if added tothe multiple-access PDN connection for transport of the given IP flow.

FIG. 5 is a flow diagram illustrating an example of a process 500 forperforming IFOM across multiple access technologies. The process 500 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2, and updated by the process 300 ofFIG. 3. The process 500 may be performed after a multi-access PDNconnection is established in other ways, as well. The process 500 may beused to request removal of and/or to remove the IP flow from themulti-access PDN connection.

As shown in block 502, the multi-access connection manager 107 may sendto the WTRU 102 a request to de-associate the IP flow from the accessnetwork 105 ₂. The multi-access connection manager 107 may send therequest responsive to a flow-updating event, and use a BU message to thesend the request. The BU message may include the second-accessconnection information.

In one embodiment, the multi-access connection manager 107 may receivefrom the WTRU an acknowledgement of the removal request, as shown inblock 504. The acknowledgement may be carried in a BA message, forinstance. The BA message may include the second-access-connectioninformation.

The multi-access connection manager 107 may obtain an acceptance of theremoval request, as shown in block 506. The multi-access connectionmanager 107 may, for example, infer the acceptance from (i) receipt ofthe BA message, (ii) not receiving a response to the BU message or (iii)not receiving a rejection of the request from the WTRU 102.Alternatively, the BA message may include an indication of theacceptance of the request.

As shown in block 508, the multi-access connection manager 107 and theWTRU 102 may de-associate the IP flow from the access network 105 ₂,responsive to acceptance of the request. To facilitate making thede-association, the WTRU 102 may extract the second-access connectioninformation from the BU message. Thereafter, the WTRU 102 mayde-associate the IP flow from the access network 105 ₂ by removing theIP-flow information from the WTRU data structure. Similarly, themulti-access connection manager 107 may de-associate the IP flow fromthe access network 105 ₂ by removing the IP-flow information from theconnection manager data structure.

FIG. 6 is a flow diagram illustrating an example of a process 600 forperforming IFOM across multiple access technologies. The process 600 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2. The process 600 may be performedafter a multi-access PDN connection is established in other ways, aswell.

The process 600 may be used to resolve and/or avert potential collisionsbetween a request associated with IFOM on a multi-access PDN connection(“IFOM request”) initiated by the network-access manager 107(“nw-initiated IFOM request”) and a IFOM request initiated by the WTRU102 (“wtru-initiated IFOM request”). To facilitate the process 600, themulti-access connection manager 107 and WTRU 102 are provisioned withrespective priorities (“nw priority” and “wtru priority”, respectively);one being subordinate to the other. The network-access manager 107 andWTRU 102 may refer to these priorities to resolve a potential collisionbetween nw-initiated and wtru-initiated IFOM requests.

Provisioning of the nw-priority and wtru priority may be performed in anumber of ways. For example, the nw-priority may be provisionedinitially to be subordinate to the wtru priority (or, conversely, thewtru priority may be provisioned subordinate to the nw priority). Thenw-priority and wtru priority may be updated repeatedly, as well. Forexample, the relative subordination of nw-priority and wtru priority maybe provisioned in response to an event, such as, for example, aflow-updating event and like-type events. Alternatively, provisioning ofthe nw-priority and wtru priority may occur responsive to one or moreconditions of the communications system 100, such as, for example,congestion and/or limited connectivity occurring (or anticipated tooccur) in and/or in association with the communications system 107,including, any of the networks 103, 110; PDN connections; linksassociated with the IP connections; access systems 105 _(1-n); and airinterfaces 116 _(1-n). Provisioning of the nw-priority and wtru prioritymay be based on one or more policies of the network 103 or thecommunications system 100, as well

As shown in block 602, the multi-access connection manager 107 may sendto the WTRU 102 an nw-initiated request to associate a given IP flowwith the multi-access PDN connection. The multi-access connectionmanager 107 may use a BU message, for example, to send the nw-initiatedrequest. After sending the nw-initiated request, the multi-accessconnection manager 107 may await a response, as shown in block 604.While awaiting the response, the multi-access connection manager 107 mayreceive from the WTRU 102 a wtru-initiated request to associate thegiven IP flow with the multi-access PDN connection, as shown in block606. Like the nw-initiated request, the WTRU may use a BU message tosend the wtru-initiated request. After receiving the wtru-initiatedrequest, the multi-access connection manager 107 may refer to thenw-priority and wtru-priority, and responsive to the nw-priority beingsubordinate to the wtru-priority, the multi-access connection manager107 may send to the WTRU 102 an acceptance to the wtru-initiatedrequest, as shown in block 608.

Although not shown in FIG. 6, if, after referring to the nw-priority andwtru-priority, the wtru-priority is subordinate to the nw-priority, thenthe multi-access connection manager 107 may again await a response tothe nw-initiated request (e.g., block 604). As another alternative, themulti-access connection manager 107 may abandon the nw-initiatedrequest.

Referring now to FIG. 7, a flow diagram illustrating an example of aprocess 700 for performing IFOM across multiple access technologies isshown. The process 700 of FIG. 7 is similar to the process 600 of FIG.6, except as described below.

After receiving the wtru-initiated request (606), the multi-accessconnection manager 107 may refer to the nw-priority and wtru-priority.Responsive to the wtru-priority being subordinate to the nw-priority(unlike 608 of FIG. 6), the multi-access connection manager 107 mayresend the nw-initiated request (or send another nw-initiated request),as shown in block 702.

Although not shown in FIG. 7, the multi-access connection manager 107may then await a response to the resent nw-initiated request. Assumingthe wtru-priority remains subordinate to nw-priority, the multi-accessconnection manager 107 may receive an acceptance to the nw-initiatedrequest from the WTRU 102.

The process 600 of FIG. 6 and the process 700 of FIG. 7 may also beperformed for the wtru-initiated request being sent prior to thenw-initiated request. For example, the WTRU 102 may await a response tothe wtru-initiated request (604), and while awaiting the response, theWTRU 102 may receive a nw-initiated request (606). If, after referringto the nw-priority and wtru-priority, the nw-priority is subordinate tothe wtru-priority (608), then the WTRU 102 may await a response to thewtru-initiated request (e.g., the acceptance to the wtru-initiatedrequest (608)), resend the wtru-initiated request or send anotherwtru-initiated request (702). If the wtru-priority is subordinate to thenw-priority, then the WTRU 102 may send to the acceptance to thenw-initiated request (608). Further, as one of ordinary skill in the artwill appreciate, block 702 of process 700 may be appended to process 600as an alternative to block 608.

FIG. 8 is a flow diagram illustrating an example of a process 800 forperforming IFOM across multiple access technologies. The process 800 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2. The process 800 may be performedafter a multi-access PDN connection is established in other ways, aswell. The process 800 may be used to resolve and/or avert potentialcollisions between an nw-initiated IFOM request and a wtru-initiatedIFOM request.

As shown in block 802, the multi-access connection manager 107 may sendto the WTRU 102 an nw-initiated request to associate a given IP flowwith the multi-access PDN connection. The multi-access connectionmanager 107 may use a BU message to send the nw-initiated request. Aftersending the nw-initiated request, the multi-access connection manager107 may await a response, as shown in block 804. While awaiting theresponse, the multi-access connection manager 107 may receive from theWTRU 102 a request to modify the nw-initiated request(“wtru-modification request”), as shown in block 806. The WTRU 102 mayuse a signaling message configured for requesting modifications to a BUmessage (“Mod-BU message”) to send the wtru-modification request. ThisMod-BU message may include requested modifications to the nw-initiatedrequest. The Mod-BU message may also include an identifier todifferentiate the wtru-modification request from other requests(“modification-request identifier”).

After extracting the requested modifications, the multi-accessconnection manager 107 may send to the WTRU 102 a request that includesthe requested modifications (“updated-nw request”), as shown in block808. The multi-access connection manager 107 may use a Mod-BU message tosend the updated-nw request, as well. The Mod-BU message may include themodification-request identifier along with the updated-nw request.

As shown in block 810, the multi-access connection manager 107 mayobtain an acceptance of the updated-nw request. The multi-accessconnection manager 107 may, for example, receive from the WTRU 102 anacknowledgement of the updated-nw request, which includes an acceptanceof the updated-nw request. The acknowledgement may be carried in a BAmessage. The BA message may include the information for confirmingacceptance of the updated-nw request. Alternatively, the multi-accessconnection manager 107 may infer the acceptance from (i) receipt of a BAmessage, (ii) not receiving a response to the Mod-BU message or (iii)not receiving a rejection of the updated-nw request from the WTRU 102.

Although not shown in FIG. 8, the multi-access connection manager 107may send to the WTRU 102 a request to modify the wtru-modificationrequest instead of sending the updated-nw request (806). This request(“nw-modification request”) may be carried in a Mod-BU message, as well.The Mod-BU message may include requested modifications to thewtru-modification request. The Mod-BU message may also include amodification-request identifier to differentiate the nw-modificationrequest from other requests (e.g., the wtru-modification request). TheWTRU 102 may accept or reject nw-modification request, and notify themulti-access connection manager 107, accordingly.

Alternatively, the WTRU 102 may send another wtru-modification requestto continue negotiating with the multi-access connection manager 107.The multi-access connection manager 107 may accept or reject the lastreceived wtru-modification request, and notify the WTRU 102,accordingly. The multi-access connection manager 107 may send yetanother nw-modification request to continue negotiating with the WTRU102. The multi-access connection manager 107 and WTRU 102 may continuenegotiations until agreement, indefinitely or until reaching a limit tothe amount of negotiation. This limit may be based on time, number ofmessages, etc.

The process 800 may also be performed for the wtru-initiated requestbeing sent prior to the nw-initiated request. By way of example, theWTRU 102 may send a wtru-initiated request to the multi-accessconnection manager 107 (802). After sending the wtru-initiated request,the WTRU 102 may await a response (804). While awaiting the response,the WTRU 102 may receive an nw-modification request from themulti-access connection manager 107 (806).

After extracting the requested modifications, the WTRU 102 may send tothe multi-access connection manager 107 a request that includes therequested modifications (“updated-wtru request”) (808). Thereafter, theWTRU 102 may use a Mod-BU message to send the updated-wtru request. TheMod-BU message may include a modification-request identifier along withthe updated-wtru request. The WTRU 102 may obtain an acceptance of theupdated-wtru request (810). The WTRU 102 may, for example, receive fromthe multi-access connection manager 107 an acknowledgement of theupdated-wtru request, which includes the acceptance of the updated-wtrurequest. The acknowledgement may be carried in a BA message sent fromthe multi-access connection manager 107. Alternatively, the WTRU 102 mayinfer the acceptance from (i) receipt of a BA message, (ii) notreceiving a response to the Mod-BU message or (iii) not receiving arejection of the request from the multi-access connection manager 107.

FIG. 9 is a flow diagram illustrating an example of a process 900 forperforming IFOM across multiple access technologies. The process 900 maybe performed after a multi-access PDN connection is established, as, forexample, by the process 200 of FIG. 2. The process 900 may be performedafter a multi-access PDN connection is established in other ways, aswell. The process 900 may be used to resolve and/or avert potentialcollisions between an nw-initiated IFOM request and a wtru-initiatedIFOM request. To facilitate the process 900, a token, whose possessionis required to initiate an IFOM request, may be made available to themulti-access connection manager 107 and to the WTRU 102. The token maybe maintained by either the multi-access connection manager 107 or theWTRU 102 by default, and returned when not being used. Alternatively, anetwork entity of the network 103 may maintain the token, and issue itto the multi-access connection manager 107 or the WTRU 102 on request.As another alternative, an instance of the token may be generated whenanother instance is not in use. The token instance may expire after useor other event (e.g., a given time period). For simplicity ofexposition, the process 900 assumes the WTRU 102 possesses the token bydefault.

As shown in block 902, the multi-access connection manager 107 mayobtain the token. Given the token is possessed by the WTRU 102, themulti-access connection manager 107 may send to the WTRU 102 a messagefor requesting for the token (“token-request message”). Thetoken-request message may be sent over the multi-access PDN connectionor, alternatively, over another connection with the WTRU 102. Responsiveto the token-request message, the WTRU 102 may send the token to themulti-access connection manager 107. After obtaining the token, themulti-access connection manager 107 may send to the WTRU 102 annw-initiated request to associate a given IP flow with the multi-accessPDN connection, as shown in block 904.

The process 900 may also be performed by the WTRU 102 for awtru-initiated IFOM request. Additionally, the multi-access connectionmanager 107 and the WTRU 102 may pass the token back and forth so as tofacilitate a change in priority. Further, as one of ordinary skill inthe art will appreciate, the process 900 may be appended to flows 300,400 and 500 as an alternative to, or in lieu of, blocks 304, 404 and502, respectively.

FIG. 10 is a flow diagram illustrating an example of a process 1000 forperforming IFOM across multiple access technologies. The process 1000may be performed after a multi-access PDN connection is established, as,for example, by the process 200 of FIG. 2. The process 1000 may beperformed after a multi-access PDN connection is established in otherways, as well. The process 1000 may be used to resolve and/or avertpotential collisions between an nw-initiated IFOM request and awtru-initiated IFOM request.

As shown in block 1002, the multi-access connection manager 107 may sendan nw-initiated request to the WTRU 102 to associate a given IP flowwith the multi-access PDN connection. The multi-access connectionmanager 107 may use a BU message to send the nw-initiated request.

After sending the nw-initiated request, the multi-access connectionmanager 107 may await a response, as shown in block 1004. While awaitingthe response, the multi-access connection manager 107 may receive fromthe WTRU 102 a wtru-initiated request to associate the given IP flowwith the multi-access PDN connection, as shown in block 1006. The WTRU102 may use a BU message to send the wtru-initiated request.

As shown in block 1008, the multi-access connection manager 107 maydetect a collision between the nw-initiated and wtru-initiated requests.The multi-access connection manager 107 may, for example, detect thecollision as a result of recognizing receipt of the wtru-initiatedrequest after sending the nw-initiated request and while awaiting aresponse to the nw-initiated request. Responsive to detecting thecollision, the multi-access connection manager 107 may send anacceptance to the wtru-initiated request to the WTRU 102, as shown inblock 1010.

Although the foregoing presumes performing the process 1000 for annw-initiated IFOM request, the process 1000 may be performed for awtru-initiated IFOM request, as well. For example, the WTRU 102 may senda wtru-initiated request to the multi-access connection manager 107 toassociate a given IP flow with the multi-access PDN connection (1002).The WTRU 102 may use a BU message to send the wtru-initiated request.

After sending the wtru-initiated request, the WTRU 102 may await aresponse (1004). While awaiting the response, the WTRU 102 may receivefrom the multi-access connection manager 107 an nw-initiated request toassociate the given IP flow with the multi-access PDN connection (1006).The multi-access connection manager 107 may use a BU message to send thenw-initiated request. The WTRU 102 may detect a collision between thenw-initiated and wtru-initiated requests (1008), for example, as aresult of recognizing receipt of the nw-initiated request while awaitinga response to the wtru-initiated request. Responsive to the collision,the WTRU 102 may send an acceptance to the wtru-initiated request to themulti-access connection manager 107 (1010).

Referring now to FIG. 11, a flow diagram illustrating an example of aprocess 1100 for performing IFOM across multiple access technologies isshown. The process 1100 of FIG. 11 is similar to the process 1000 ofFIG. 10, except as described below.

As shown in block 1102, the multi-access connection manager 107 mayreceive from the WTRU 102 an acceptance of the nw-initiated request inresponsive to any of the nw-initiated request and the acceptance of thewtru-initiated request. The acceptance of the nw-initiated request maybe sent using a BU message. The multi-access connection manager 107 maysend to the WTRU 102 a confirmation of the acceptance of thenw-initiated request, as shown in block 1104. The confirmation may besent using a signaling message configured to confirm an acceptance of apreviously accepted binding request (“binding confirmation message”).

Although the foregoing presumes performing the process 1100 for annw-initiated IFOM request, the process 1100 may be performed for awtru-initiated IFOM request, as well.

FIGS. 12A-12E (collectively “FIG. 12”) are block diagrams illustratingan example communications system 1200 in which one or more disclosedembodiments may be implemented. Like the communications system 100, thecommunications system 1200 may be suitable for implementing and/orcarrying out any of bandwidth management, bandwidth aggregation and IFOMacross multiple access technologies.

The communications system 1200 may be a multiple access system thatprovides content, such as voice, data, video, messaging, broadcast,etc., to multiple wireless users. For instance, the communicationssystem 1200 may define an architecture that supports a plurality ofaccess systems over which the multiple wireless users may access and/orexchange the content, and that supports having two or more of the accesssystems use and/or be configured in accordance with multiple accesstechnologies. The communications system 1200 may enable the wirelessusers to access the content through sharing and/or distribution ofsystem resources, including, for example, wireless bandwidth. Thecommunications system 1200, for example, may employ one or more channelaccess methods, such as code division multiple access (CDMA), timedivision multiple access (TDMA), frequency division multiple access(FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and thelike.

The communications system 1200 may include wireless transmit/receiveunits (“WTRUs”) 1202 a, 1202 b, 1202 c and 1202 d, a radio accessnetwork (“RAN”) 1204, a core network 1206, a public switched telephonenetwork (“PSTN”) 1208, an internet 1210, and other networks 1212, thoughit will be appreciated that the disclosed embodiments contemplate anynumber of WTRUs, base stations, networks, and/or network elements.

Each of the WTRUs 1202 a, 1202 b, 1202 c and 1202 d may be any type ofdevice configured to operate and/or communicate in a wirelessenvironment. By way of example, the WTRUs 1202 a, 1202 b, 1202 c and1202 d may be configured to transmit and/or receive wireless signals,and may include user equipment (“UE”), a mobile station, a fixed ormobile subscriber unit, a pager, a cellular telephone, a personaldigital assistant (“PDA”), a Smartphone, a laptop, a netbook, a personalcomputer, a wireless sensor, consumer electronics, and the like.

The communications system 1200 may also include a base station 1214 aand a base station 1214 b. Each of the base stations 1214 a, 1214 b maybe any type of device configured to wirelessly interface with at leastone of the WTRUs and 1202 d, and may facilitate access to one or morecommunication networks, such as the core network 1206, the internet1210, and/or the other networks 1212. The base stations 1214 a, 1214 bmay be, for example, any of a base transceiver station (“BTS”), aNode-B, an eNodeB, a Home Node-B, a Home eNodeB, a site controller, anaccess point (“AP”), a wireless router, and the like. Although depictedas a single element, each of the base stations 1214 a, 1214 b maynonetheless include any number of communicatively coupled base stationsand/or network elements.

The base station 1214 a may be part of the RAN 1204. As described inmore detail below, the RAN 1204 may include base stations and/or networkelements other than the base station 1214 a (not shown), such as a basestation controller (“BSC”), a radio network controller (“RNC”), relaynodes, etc. The base station 1214 a and/or the base station 1214 b maybe configured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 1214 a may be divided intothree sectors. Thus, in one embodiment, the base station 1214 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 1214 a may employ multiple-inputmultiple output (“MIMO”) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 1214 a, 1214 b may communicate with one or more of theWTRUs 1202 a, 1202 b, 1202 c and 1202 d over an air interface 1216,which may be any suitable wireless communication link (e.g., radiofrequency (“RF”), microwave, infrared (“IR”), ultraviolet (“UV”),visible light, etc.). The air interface 1216 may be established usingany suitable radio access technology (“RAT”).

More specifically, as noted above, the communications system 1200 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 1214 a in the RAN 1204 and the WTRUs 1202 a,1202 b and 1202 c may implement a radio technology such as UniversalMobile Telecommunications System (“UMTS”) Terrestrial Radio Access(“UTRA”), which may establish the air interface 1216 using wideband CDMA(“WCDMA”). WCDMA may include communication protocols such as High-SpeedPacket Access (“HSPA”) and/or Evolved HSPA (“HSPA+”). HSPA may includeHigh-Speed DL Packet Access (“HSDPA”) and/or High-Speed UL Packet Access(“HSUPA”).

In another embodiment, the base station 1214 a and the WTRUs 1202 a,1202 b and 1202 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (“E-UTRA”), which may establish the airinterface 1216 using Long Term Evolution (“LTE”) and/or LTE-Advanced(“LTE-A”).

In other embodiments, the base station 1214 a and the WTRUs 1202 a, 1202b and 1202 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (“WiMAX”)), CDMA2000,CDMA2000 12×, CDMA2000 EV-DO, Interim Standard 2000 (“IS-2000”), InterimStandard 95 (“IS-95”), Interim Standard 856 (“IS-856”), Global Systemfor Mobile communications (“GSM”), Enhanced Data rates for GSM Evolution(“EDGE”), GSM EDGE (“GERAN”), and the like.

The base station 1214 b in FIG. 12A may be a wireless router, HomeNode-B, Home eNodeB, or access point, for example, and may utilize anysuitable RAT for facilitating wireless connectivity in a localized area,such as a place of business, a home, a vehicle, a campus, and the like.In one embodiment, the base station 1214 b and the WTRUs 1202 c, 1202 dmay implement a radio technology such as IEEE 802.11 to establish awireless local area network (“WLAN”). In another embodiment, the basestation 1214 b and the WTRUs 1202 c, 1202 d may implement a radiotechnology such as IEEE 802.15 to establish a wireless personal areanetwork (“WPAN”). In yet another embodiment, the base station 1214 b andthe WTRUs 1202 c, 1202 d may utilize a cellular-based RAT (e.g., WCDMA,CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.As shown in FIG. 12A, the base station 1214 b may have a directconnection to the Internet 1210. Thus, the base station 1214 b may notbe required to access the Internet 1210 via the core network 1206.

The RAN 1204 may be in communication with the core network 1206, whichmay be any type of network configured to provide voice, data,applications, and/or voice over internet protocol (“VoIP”) services toone or more of the WTRUs 1202 a, 1202 b, 1202 c and 1202 d. For example,the core network 1206 may provide call control, billing services, mobilelocation-based services, pre-paid calling, Internet connectivity, videodistribution, etc., and/or perform high-level security functions, suchas user authentication. Although not shown in FIG. 12A, it will beappreciated that the RAN 1204 and/or the core network 1206 may be indirect or indirect communication with other RANs that employ the sameRAT as the RAN 1204 or a different RAT. For example, in addition tobeing connected to the RAN 1204, which may be utilizing an E-UTRA radiotechnology, the core network 1206 may also be in communication withanother RAN (not shown) employing a GSM radio technology.

The core network 1206 may also serve as a gateway for the WTRUs 1202 a,1202 b, 1202 c and 1202 d to access the PSTN 1208, the Internet 1210,and/or other networks 1212. The PSTN 1208 may include circuit-switchedtelephone networks that provide plain old telephone service (“POTS”).The Internet 1210 may include a global system of interconnected computernetworks and devices that use common communication protocols, such asthe transmission control protocol (“TCP”), user datagram protocol(“UDP”) and the internet protocol (“IP”) in the TCP/IP internet protocolsuite. The networks 1212 may include wired or wireless communicationsnetworks owned and/or operated by other service providers. For example,the networks 1212 may include another core network connected to one ormore RANs, which may employ the same RAT as the RAN 1204 or a differentRAT.

Some or all of the WTRUs 1202 a, 1202 b, 1202 c and 1202 d of thecommunications system 1200 may include multi-mode capabilities, i.e.,the WTRUs 1202 a, 1202 b, 1202 c and 1202 d may include multipletransceivers for communicating with different wireless networks overdifferent wireless links. For example, the WTRU 1202 c shown in FIG. 12Amay be configured to communicate with the base station 1214 a, which mayemploy a cellular-based radio technology, and with the base station 1214b, which may employ an IEEE 802 radio technology.

FIG. 12B is a block diagram illustrating example architecture of a WTRU,such as the WTRU 1202 of FIG. 12A. As shown in FIG. 12B, the WTRU 1202may include a processor 1218, a transceiver 1220, a transmit/receiveelement 1222, a speaker/microphone 1224, a keypad 1226, adisplay/touchpad 1228, a non-removable memory 1230, a removable memory1232, a power source 1234, a global positioning system (“GPS”) chipset1236, and other peripherals 1238. It will be appreciated that the WTRU1202 may include any sub-combination of the foregoing elements whileremaining consistent with an embodiment.

The processor 1218 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (“DSP”),a plurality of microprocessors, one or more microprocessors inassociation with a DSP core, a controller, a microcontroller,Application Specific Integrated Circuits (“ASICs”), Field ProgrammableGate Array (“FPGAs”) circuits, any other type of integrated circuit(“IC”), a state machine, and the like. The processor 1218 may performsignal coding, data processing, power control, input/output processing,and/or any other functionality that enables the WTRU 1202 to operate ina wireless environment. The processor 1218 may be coupled to thetransceiver 1220, which may be coupled to the transmit/receive element1222. While FIG. 12B depicts the processor 1218 and the transceiver 1220as separate components, it will be appreciated that the processor 1218and the transceiver 1220 may be integrated together in an electronicpackage or chip.

The transmit/receive element 1222 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 1214a) over the air interface 1216. For example, in one embodiment, thetransmit/receive element 1222 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 1222 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 1222 may be configured totransmit and receive both RF and light signals. It will be appreciatedthat the transmit/receive element 1222 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 1222 is depicted inFIG. 12B as a single element, the WTRU 1202 may include any number oftransmit/receive elements 1222. More specifically, the WTRU 1202 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 1202 mayinclude two or more transmit/receive elements 1222 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 1216.

The transceiver 1220 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 1222 and to demodulatethe signals that are received by the transmit/receive element 1222. Asnoted above, the WTRU 1202 may have multi-mode capabilities. Thus, thetransceiver 1220 may include multiple transceivers for enabling the WTRU1202 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 1218 of the WTRU 1202 may be coupled to, and may receiveuser input data from, the speaker/microphone 1224, the keypad 1226,and/or the display/touchpad 1228 (e.g., a liquid crystal display (“LCD”)display unit or organic light-emitting diode (“OLED”) display unit). Theprocessor 1218 may also output user data to the speaker/microphone 1224,the keypad 1226, and/or the display/touchpad 1228. In addition, theprocessor 1218 may access information from, and store data in, any typeof suitable memory, such as the non-removable memory 1230 and/or theremovable memory 1232. The non-removable memory 1230 may includerandom-access memory (“RAM”), read-only memory (“ROM”), a hard disk, orany other type of memory storage device. The removable memory 1232 mayinclude a subscriber identity (“ID”) module (“SIM”) card, a memorystick, a secure digital (“SD”) memory card, and the like. In otherembodiments, the processor 1218 may access information from, and storedata in, memory that is not physically located on the WTRU 1202, such ason a server or a home computer (not shown).

The processor 1218 may receive power from the power source 1234, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 1202. The power source 1234 may be any suitabledevice for powering the WTRU 1202. For example, the power source 1234may include one or more dry cell batteries (e.g., nickel-cadmium(“NiCd”), nickel-zinc (“NiZn”), nickel metal hydride (“NiMH”),lithium-ion (“Li-ion”), etc.), solar cells, fuel cells, and the like.

The processor 1218 may also be coupled to the GPS chipset 1236, whichmay be configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 1202. In additionto, or in lieu of, the information from the GPS chipset 1236, the WTRU1202 may receive location information over the air interface 1216 from abase station (e.g., base stations 1214 a, 1214 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It will be appreciated that the WTRU 1202 mayacquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 1218 may further be coupled to other peripherals 1238,which may include one or more software and/or hardware modules thatprovide additional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 1238 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (“USB”) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (“FM”) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 12C is a block diagram illustrating example architectures of theRAN 1204 and core network 1206 according to an embodiment. The RAN 1204may be an access service network (“ASN”) that employs IEEE 802.16 radiotechnology to communicate with the WTRUs 1202 a, 1202 b and 1202 c overthe air interface 1216. As will be further discussed below, thecommunication links between the different functional entities of theWTRUs 1202 a, 1202 b and 1202 c, the RAN 1204, and the core network 1206may be defined as reference points.

As shown in FIG. 12C, the RAN 1204 may include base stations 1270 a, 127b and 1270 c, and an ASN gateway 1242, though it will be appreciatedthat the RAN 1204 may include any number of base stations and ASNgateways while remaining consistent with an embodiment. The basestations 1270 a, 1270 b and 1270 c may each be associated with aparticular cell (not shown) in the RAN 1204 and may each include one ormore transceivers for communicating with the WTRUs 1202 a, 1202 b and1202 c over the air interface 1216. In one embodiment, the base stations1270 a, 1270 b and 1270 c may implement MIMO technology. Thus, the basestation 1270 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 1202 a.The base stations 1270 a, 1270 b and 1270 c may also provide mobilitymanagement functions, such as handoff triggering, tunnel establishment,radio resource management, traffic classification, quality of service(“QoS”) policy enforcement, and the like. The ASN gateway 1242 may serveas a traffic aggregation point and may be responsible for paging,caching of subscriber profiles, routing to the core network 1206, andthe like.

The air interface 1216 between the WTRUs 1202 a, 1202 b and 1202 c andthe RAN 1204 may be defined as an R1 reference point that implements theIEEE 802.16 specification. In addition, each of the WTRUs 1202 a, 1202 band 1202 c may establish a logical interface (not shown) with the corenetwork 1206. The logical interface between the WTRUs 1202 a, 1202 b and1202 c and the core network 1206 may be defined as an R2 referencepoint, which may be used for authentication, authorization, IP hostconfiguration management, and/or mobility management.

The communication link between each of the base stations 1240 a, 1240 band 1240 c may be defined as an R8 reference point that includesprotocols for facilitating WTRU handovers and the transfer of databetween base stations. The communication link between the base stations1240 a, 1240 b and 1240 c and the ASN gateway 1242 may be defined as anR6 reference point. The R6 reference point may include protocols forfacilitating mobility management based on mobility events associatedwith each of the WTRUs 1202 a, 1202 b, 1200 c.

As shown in FIG. 12C, the RAN 1204 may be connected to the core network1206. The communication link between the RAN 1204 and the core network1206 may be defined as an R3 reference point that includes protocols forfacilitating data transfer and mobility management capabilities, forexample. The core network 1206 may include a mobile IP (“MIP”) homeagent (“MIP-HA”) 1244, an authentication, authorization, accounting(“AAA”) server 1246, and a gateway 1248. While each of the foregoingelements is depicted as part of the core network 1206, it will beappreciated that any one of these elements may be owned and/or operatedby an entity other than the core network operator.

The MIP-HA may be responsible for IP address management, and may enablethe WTRUs 1202 a, 1202 b and 1202 c to roam between different ASNsand/or different core networks. The MIP-HA 1244 may provide the WTRUs1202 a, 1202 b and 1202 c with access to packet-switched networks, suchas the Internet 1210, to facilitate communications between the WTRUs1202 a, 1202 b and 1202 c and IP-enabled devices. The AAA server 1246may be responsible for user authentication and for supporting userservices. The gateway 1248 may facilitate interworking with othernetworks. For example, the gateway 1248 may provide the WTRUs 1202 a,1202 b and 1202 c with access to circuit-switched networks, such as thePSTN 1208, to facilitate communications between the WTRUs 1202 a, 1202 band 1202 c and traditional land-line communications devices. Inaddition, the gateway 1248 may provide the WTRUs 1202 a, 1202 b and 1202c with access to the networks 1212, which may include other wired orwireless networks that are owned and/or operated by other serviceproviders.

Although not shown in FIG. 12C, it will be appreciated that the RAN 1204may be connected to other ASNs and the core network 1206 may beconnected to other core networks. The communication link between the RAN1204 the other ASNs may be defined as an R4 reference point, which mayinclude protocols for coordinating the mobility of the WTRUs 1202 a,1202 b and 1202 c between the RAN 1204 and the other ASNs. Thecommunication link between the core network 1206 and the other corenetworks may be defined as an R5 reference, which may include protocolsfor facilitating interworking between home core networks and visitedcore networks.

FIG. 12D is a block diagram illustrating an example of the RAN 1204 andthe core network 1206. As noted above, the RAN 1204 may employ a UTRAradio technology to communicate with the WTRUs 1202 a, 1202 b and 1202 cover the air interface 1216. The RAN 1204 may also be in communicationwith the core network 1206. As shown in FIG. 12D, the RAN 1204 mayinclude Node-Bs 1240 a, 1240 b and 1240 c, which may each include one ormore transceivers for communicating with the WTRUs 1202 a, 1202 b and1202 c over the air interface 1216. The Node-Bs 1240 a, 1240 b and 1240c may each be associated with a particular cell (not shown) within theRAN 1204. The RAN 1204 may also include RNCs 1242 a, 1242 b. It will beappreciated that the RAN 1204 may include any number of Node-Bs and RNCswhile remaining consistent with an embodiment.

As shown in FIG. 12D, the Node-Bs 1240 a, 1240 b may be in communicationwith the RNC 1242 a. Additionally, the Node-B 1240 c may be incommunication with the RNC 142 b. The Node-Bs 1240 a, 1240 b and 1240 cmay communicate with the respective RNCs 1242 a, 1242 b via an Iubinterface. The RNCs 1242 a, 1242 b may be in communication with oneanother via an Iur interface. Each of the RNCs 1242 a, 1242 b may beconfigured to control the respective Node-Bs 1240 a, 1240 b and 1240 cto which it is connected. In addition, each of the RNCs 1242 a, 1242 bmay be configured to carry out or support other functionality, such asouter loop power control, load control, admission control, packetscheduling, handover control, macrodiversity, security functions, dataencryption, and the like.

The core network 1206 shown in FIG. 12D may include a media gateway(“MGW”) 1244, a mobile switching center (“MSC”) 1246, a serving GPRSsupport node (“SGSN”) 1248, and/or a gateway GPRS support node (“GGSN”)1250. While each of the foregoing elements is depicted as part of thecore network 1206, it will be appreciated that any one of these elementsmay be owned and/or operated by an entity other than the core networkoperator.

The RNC 1242 a in the RAN 1204 may be connected to the MSC 1246 in thecore network 1206 via an IuCS interface. The MSC 1246 may be connectedto the MGW 1244. The MSC 1246 and the MGW 1244 may provide the WTRUs1202 a, 1202 b and 1202 c with access to circuit-switched networks, suchas the PSTN 1208, to facilitate communications between the WTRUs 1202 a,1202 b and 1202 c and traditional land-line communications devices.

The RNC 1242 a in the RAN 1204 may also be connected to the SGSN 1248 inthe core network 1206 via an IuPS interface. The SGSN 1248 may beconnected to the GGSN 1250. The SGSN 1248 and the GGSN 1250 may providethe WTRUs 1202 a, 1202 b and 1202 c with access to packet-switchednetworks, such as the Internet 1210, to facilitate communicationsbetween and the WTRUs 1202 a, 1202 b and 1202 c and IP-enabled devices.

As noted above, the core network 1206 may also be connected to thenetworks 1212, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 12E is a block diagram illustrating an example of the RAN 1204 andthe core network 1206. As noted above, the RAN 1204 may employ an E-UTRAradio technology to communicate with the WTRUs 1202 a, 1202 b and 1202 cover the air interface 1216. The RAN 1204 may also be in communicationwith the core network 1206.

The RAN 1204 may include eNode-Bs 1260 a, 1260 b and 1260 c, though itwill be appreciated that the RAN 1204 may include any number of eNode-Bswhile remaining consistent with an embodiment. The eNode-Bs 1260 a, 1260b and 1260 c may each include one or more transceivers for communicatingwith the WTRUs 1202 a, 1202 b and 1202 c over the air interface 1216. Inone embodiment, the eNode-Bs 1260 a, 1260 b and 1260 c may implementMIMO technology. Thus, the eNode-B 1260 a, for example, may use multipleantennas to transmit wireless signals to, and receive wireless signalsfrom, the WTRU 1202 a.

Each of the eNode-Bs 1260 a, 1260 b and 1260 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 12E, theeNode-Bs 1260 a, 1260 b and 1260 c may communicate with one another overan X2 interface.

The core network 1206 shown in FIG. 12E may include a mobilitymanagement gateway (“MME”) 1262, a serving gateway 1264, and a packetdata network (“PDN”) gateway 1266. While each of the foregoing elementsis depicted as part of the core network 1206, it will be appreciatedthat any one of these elements may be owned and/or operated by an entityother than the core network operator.

The MME 1262 may be connected to each of the eNode-Bs 1260 a, 1260 b and1260 c in the RAN 1204 via an S1 interface and may serve as a controlnode. For example, the MME 1262 may be responsible for authenticatingusers of the WTRUs 1202 a, 1202 b and 1202 c, beareractivation/deactivation, selecting a particular serving gateway duringan initial attach of the WTRUs 1202 a, 1202 b and 1202 c, and the like.The MME 1262 may also provide a control plane function for switchingbetween the RAN 1204 and other RANs (not shown) that employ other radiotechnologies, such as GSM or WCDMA.

The serving gateway 1264 may be connected to each of the eNode Bs 1260a, 1260 b and 1260 c in the RAN 1204 via the S1 interface. The servinggateway 1264 may generally route and forward user data packets to/fromthe WTRUs 1202 a, 1202 b and 1202 c. The serving gateway 1264 may alsoperform other functions, such as anchoring user planes duringinter-eNode B handovers, triggering paging when downlink data isavailable for the WTRUs 1202 a, 1202 b and 1202 c, managing and storingcontexts of the WTRUs 1202 a, 1202 b and 1202 c, and the like.

The serving gateway 1264 may also be connected to the PDN gateway 1266,which may provide the WTRUs 1202 a, 1202 b and 1202 c with access topacket-switched networks, such as the Internet 1210, to facilitatecommunications between the WTRUs 1202 a, 1202 b and 1202 c andIP-enabled devices.

The core network 1206 may facilitate communications with other networks.For example, the core network 1206 may provide the WTRUs 1202 a, 1202 band 1202 c with access to circuit-switched networks, such as the PSTN1208, to facilitate communications between the WTRUs 1202 a, 1202 b and1202 c and traditional land-line communications devices. For example,the core network 1206 may include, or may communicate with, an IPgateway (e.g., an IP multimedia subsystem (“IMS”) server) that serves asan interface between the core network 1206 and the PSTN 1208. Inaddition, the core network 1206 may provide the WTRUs 1202 a, 1202 b and1202 c with access to the networks 1212, which may include other wiredor wireless networks that are owned and/or operated by other serviceproviders.

FIG. 13 is a block diagram illustrating an example of a communicationssystem 1300 in which one or more disclosed embodiments may beimplemented and/or carried out. The communications system 1300 may besuitable for implementing and/or carrying out any of BWM, BWA and IFOMacross multiple access technologies. And like the communications systems100, 1200 of FIGS. 1, 12A-E, respectively, the communications system1300 may include multiple access systems configured in accordance withmultiple access technologies.

The communications system 1300 may include a WTRU 1302 and a network1303. The network 1303 may be configured, for example, in accordancewith a home mobility service architecture for interworking WLAN(“I-WLAN”) mobility. The network 1303 may include first and secondaccess systems 13051, 13052, a home agent (“HA”) 1307, anauthentication, authorization and accounting (“AAA”) server 1346, a homesubscriber server (“HSS”) 1318 and network control nodes 1330interfacing with the HA 1307. The AAA server 1346 may be, for example, a3GPP AAA server. As shown, the HA 1307 may communicate with an externalPDN 1310 via an HGi interface. The external PDN 1310 may be, forexample, any of a public internet network and an operator servicenetwork.

The first access system 1305 ₁ may be configured in accordance with atleast one release of 3GPP, and/or an access technology protocol of anon-3GPP cellular or cellular-like protocol (collectively hereinafter“3GPP/Cellular access system 1305 ₁”). The 3GPP/Cellular access system1305 ₁ may include, for example, a GERAN/UTRAN 1304 ₁, a SGSN 1348 and aGGSN/access router (“AR”) 1350. The GERAN/UTRAN 1304 ₁ may communicatewith the WTRU 102 via a Uu/Um interface, and with the SGSN 1348 via anIu_ps/Gb interface. The SGSN 1348 may communicate with the GGSN/AR 1350using a Gn interface. The GGSN/AR 1350 may communicate with the HA 1307via a connection established using an H3 reference point (“H3connectivity”).

The second access system 1305 ₂ may be configured in accordance with anaccess technology of a WLAN, WPAN and like-type wireless networks(collectively hereinafter “WLAN access system 1305 ₂”). The WLAN accesssystem 1305 ₂ may include a WLAN access network 1304 ₂, a WLAN accessgateway (“WAG”) 1342 and a PDG/AR 1316. The WLAN access network 1305 ₂may communicate with the WTRU 1302 via a Ww interface, and with the WAG1342 via a Wn interface. The WAG 1314, in turn, may communicate with thePDG/AR 1316 using a Wp interface. The PDG/AR 1316 may communicate withthe HA 1307 using H3 connectivity.

The WTRU 1302 may communicate with the PDG/AR 1316 via a Wu interface.The Wu interface may be a defined interface of the WLAN access network13052, for example. The WTRU 1302 and the HA 1307 may communicate via aconnection established using, for example, an H1 reference point (“H1connection”). The H1 connection may be established via any of the3GPP/Cellular and WLAN access systems 1305 ₁, 1305 ₂. The H1 interfacemay be realized via a Dual Stack MIP (“DSMIP”) tunnel between the WTRU1302 and HA 1307 inside an IPSec tunnel between the WTRU 1302 and PDG/AR1316.

The HA 1307 and WTRU 1302 may, for example, exchange signaling messagesover the H1 connection. The signaling messages may include DSMIPv4signaling messages; DSMIPv6 signaling messages; signaling messages thatare based on, extensions of, related to, modifications of the DSMIPv4and DSMIPv6 signaling messages; and other like-type signaling messages(collectively “DSMIP signaling messages”). Examples of the DSMIPsignaling messages include a binding update (“BU”) message, a bindingacknowledgment (“BA”) message, a reject binding update (“Rej-BU”)message, a modify binding update request (“Mod-BU”) message and abinding confirmation (“BC”) message.

The HA 1307 and WTRU 1302 may use the DSMIP signaling messages, forexample, to keep track of which of the 3GPP/Cellular and WLAN accesssystems 1305 ₁, 1305 ₂ the WTRU 220 is camping on and/or has recentlycamped on. The HA 1307 and WTRU 1302 may also use the DSMIP signalingmessages to facilitate multi access PDN connectivity and IFOM (“MAPIM”),as described in more detail below. The DSMIP signaling messages maytraverse the H1 connection using UDP over IP, and may be transparent tothe GGSN/AR 1350 and the PDG/AR 1316.

Although the HA 1307 is shown as a stand-alone entity in FIG. 13, the HA1307 may be co-located with and/or distributed among any of the GGSN/AR1350, PDG/AR 1316 or another entity of the 3GPP/Cellular and/or WLANaccess systems 1305 ₁, 1305 ₂ (not shown). Alternatively, functionalityof the HA 1307 may be distributed among any of the GGSN/AR 1350, PDG/AR1316 or another entity of the 3GPP/Cellular and/or WLAN access systems1305 ₁, 1305 ₂.

FIGS. 14A-14B are block diagrams illustrating an example of acommunications system 1400 in which one or more disclosed embodimentsmay be implemented and/or carried out. The communications system 1400may be suitable for implementing and/or carrying out any of bandwidthmanagement, bandwidth aggregation and IFOM across multiple accesstechnologies.

The communications system 1400 may include a WTRU 1402 and an enhancedpacket core (“EPC”) network (shown generally 1403). The EPC network 1403may include a 3GPP access 1404 ₁, a trusted non-3GPP access 1404 ₂, anuntrusted non-3GPP access 1404 ₃, a HA 1407 (FIG. 14B), a HSS 1418, apolicy and charging rules function (“PCRF”) 1420, an access networkdiscovery and selection function (“ANDSF”) 1422, a network monitoringand control function (“NMCF”) 1424, an evolved PDG (“ePDG”) 1426, a 3GPPAAA server 1446, a SGW 1464 and a PGW 1466. Although the PGW 1466includes the functionality of HA 1407, as shown in FIG. 14B, suchfunctionality of the HA 1407 may be implemented as a stand-alone entity,as an entity of the EPC 1403 other than the PGW 1466. As an alternative,the functionality of the HA 1407 may be distributed among a number ofentities of the EPC network 1403. As another alternative, the HA 1407may be co-located with any of the PGW 1466 and another entity of the EPCnetwork 1403 (not shown).

The EPC 1403 may define a 3GPP access system 1405 ₁, atrusted-non-3GPP-access system 1405 ₂ (e.g., a 1evDo access system) andan untrusted-non-3GPP-access system 1405 ₃ (e.g., a WLAN access system).As shown, the 3GPP access system 1405 ₁ may include the 3GPP accessnetwork 1404 ₁, the SGW 1464 and the PGW 1466. Thetrusted-non-3GPP-access system 1405 ₂ may include the trusted non-3GPPaccess 1404 ₂, and the PGW 1466. The untrusted-non-3GPP-access system1405 ₃ may include the untrusted non-3GPP access 1404 ₃, the ePDG 1426and the PGW 1466.

The WTRU 1402 may exchange DSMIP signaling messages with the HA 1407 viaany of the 3GPP access system 1405 ₁, trusted-non-3GPP-access system1405 ₂ and untrusted-non-3GPP-access system 1405 ₃. The DSMIP signalingmessages may be carried via an S2c interface or any other suitableinterface.

The NMCF 1424 may collect metrics (e.g., any of congestion,connectivity, loads, latency, etc.) for local radio and backhaul linksvia interfaces on the 3GPP access 1404 ₁, trusted non-3GPP access 1404₂, and untrusted non-3GPP access 1404 ₃. These local radio and backhaulmetrics may include radio reports obtained from the WTRU 1402 (“WTRUradio reports”), from the untrusted non-3GPP access 1404 ₃ (e.g., WLANAP radio reports”), and from the 3GPP access 1404 ₁ (e.g., eNB radionetwork reports). For scalability, these local radio and backhaulmetrics may be aggregated by network edge nodes (aggregation points) forexchange with the NMCF 1424. The ePDG 1426 may be the aggregation pointfor links of the untrusted non-3GPP access 1404 ₃. For the 3GPP access1404 ₁, the SGW 1464 may be the aggregation point for the multiple eNBs.Aggregation may be based on an OAM-type interface to permit informationsuch as performance data and alarm notifications are conveyed, howeverreal-time status is required for making accurate decisions. The lattermay include probing or passive monitoring techniques. One such functionis the generation of statistics related to packet retransmissions. Whenthe number or rate of retransmissions in a particular RAT reaches anoperator's defined maximum, or retransmission threshold, the NMCF 1424may send such statistics to a retransmission coordination function(“RCF”)(not shown). Such statistics may be sent on a per-access-basis.Retransmission threshold values may be defined as policies per access inan evolved PCRF (“ePCRF”).

The NMCF 1424 may provide the information to a BWM function (“BWMF”)that may also be implemented as part of an evolved and/or enhanced PCEF(“ePCEF”). The NMCF 1424 may directly exchange information with the PCRF1420 via an interface defined between the NMCF 1424 and PCRF 1420; forexample interface S7a. This S7a may be based on a modification on S7/Gxinterface.

The NMCF 1424 may send to an enhanced ANDSF (“eANDSF”) updates formodifying WTRU-specific policies based on current network loads. TheWTRU 1402 may request this information from the eANDSF as required or itmay be pushed to the WTRU 1402 based on some event trigger.

Alternatively, the NMCF 1424 may send updates to a subscriber profilerepository (“SPR”) that may be enhanced (e.g, configured) with BWMpolicy-related information, if, for example, a direct interface betweenNMCF and eANDSF is not available. The enhanced SPR (“eSPR”) may providesuch updates to the eANDSF so as to allow to the eANDSF to modify theWTRU-specific policies based on current network loads. An interfacebetween eANDSF and eSPR may be realized as a manifestation of the Udinterface. An interface the NMCF 1424 and ePCRF may also be realized viaUd.

To enable IP flow level control, the ANDSF 1422 may include IP flowclass specific inter system mobility policies. These inter-systemmobility policies may be provided by a network operator, and may bedefined per access point name (“APN”), per IP flow class under any APNor per IP flow class under a specific APN.

The IP flow class may be identified via any of a media type (e.g.audio), IMS Communication Service Identifier (e.g., MMTEL) for IMSapplications and respective 5-tuple (IP source address, IP destinationaddress, source port, destination port, protocol type) for any type ofapplication. The 5-tuple may include wildcard values in any of thepossible fields. For example, the ANDSF 1422 may indicate that 3GPP hasa highest priority access for a given IP flow class, and a Wi-Fi has ahighest priority access for another IP flow class.

When establishing the connection with the ANDSF 1422, the WTRU 1402 mayindicate to the ANDSF 1422 a capability to support IP flow classspecific inter system mobility policies. Based on policies provided bythe ANDSF 1422, the WTRU 1402 may send a request to the HA 1407 to routeIP flows to an appropriate access.

The WTRU 1402 may include an application, e.g., a client application, tofacilitate exchange of the DSMIP signaling messages and/or user datatransfer with the HA 1407 (hereinafter “DSMIP client”). The DSMIP clientmay be configured with IFOM functionality, as well. The HA 1407 mayinclude corresponding functionality.

Referring now to FIG. 15A, a block diagram illustrating protocols thatmay be used to provide any of BMW, BWA and IFOM in a communicationssystem is shown. This communications system may be any of thecommunications systems disclosed herein as well as other applicablecommunications systems. For simplicity of exposition, the protocols ofFIG. 15A are described with reference to the communications system 1400.

The WTRU 1402, the untrusted non-3GPP access 1404 ₃, 3GPP access 1404 ₁,the PGW/HA 1466/1407 and a server/peer 1550 may include IP layers 1552.The WTRU 1402 and the 3GPP access 1404 ₁ may also include a cellularlayer 1554. The WTRU 1402 and the untrusted non-3GPP access 1404 ₃ mayalso include a WLAN layer 1556. The untrusted non-3GPP access 1404 ₃,3GPP access 1404 ₁, the PGW/HA 1466/1407 and the server/peer 1550 mayinclude layer 1 (L1) and layer 2 (L2) (shown collectively “L2-L1”) 1557.The WTRU 2702 and a server/peer 1550 may include respective TCP layers1558. The WTRU 2702 and the PGW/HA 1466/1407 may include a top routingprotocol layer 1560 and a combined DSMIP and IFOM protocol layer 1562.

The DSMIP client and equivalent functionality of the HA 1407 mayimplement the combined DSMIP and IFOM protocol layer 1562. The combinedDSMIP and IFOM protocol layer may include an IFOM routing engine. TheIFOM routing engine may be adapted to steer a given IP flow toward agiven access system, such as the 3GPP access 1404 ₁ and/or towards theuntrusted non-3GPP access 1404 ₃. Such steering may be based on one ormore Inter-System Routing Policies (“ISRPs”) received from ANDSF 1422 orbased on network initiated policies, such as disclosed herein.

At the top routing layer 1560, the WTRU 1402 and/or the HA 1407 may makea routing decision between the HoA and a Local CoA (“CoA-L”) fornon-seamless offload. This routing decision may be on a per-flow basis

FIG. 15B is a chart illustrating an example of a flow table 1500 forperforming IFOM across multiple access technologies. The flow table 1500may be representative of a binding cache of a HA and/or a binding listof a WTRU. The flow table 1500 defines, for each multi-access PDNconnection, a mapping between routing addresses and an anchor or homeaddress along with a mapping between the routing addresses andrespective IP flows.

The flow table 1500 may define a first binding 1502 between an anchoraddress (“HoA1”) and a first routing address (“CoA1”), and a secondbinding 1504 between the HoA1 and a second routing address (“CoA2”). Thefirst binding 1502 may include a binding ID (“BID”), namely, BID 1, andthe second binding may include BID 2.

The first binding 1502 may include first and second flow registrations1506, 1508. The first flow registration 1506 may include a flowidentifier (“FID”), namely, FID 1, and a first routing filter. Thesecond flow registration 1508 may include FID 2 and a second routingfilter.

The second binding 1504 may include a third flow registration 1510. Thethird flow registration 1510 may include FID 2 and a third routingfilter.

FIG. 16 is a message flow diagram illustrating an example of a process1600 for establishing a multiple access PDN connection with support forIFOM. The process 1600 is described with reference to the communicationssystem 1400 of FIGS. 14A-14B and to the flow table 1500 of FIG. 15B. Theprocess 1600 may be carried out using other communications systems, aswell.

The WTRU 1402 may establish an initial PDN connection with the PGW 1466through the 3GPP access system 1405 ₁ (1602). During establishment ofthe initial PDN connection, the anchor address HoA1 may be assigned tothe WTRU 1402. After establishing the initial PDN connection, the WTRU1402 may perform HA discovery, DSMIPv6 bootstrapping and home linkdetection (1604).

Thereafter, the WTRU 1402 may discover the untrusted non-3GPP accesssystem 1405 ₃, establish connectivity and obtain the routing addressCoA1 (1606). The WTRU 1402 may perform HA discovery, DSMIPv6bootstrapping and DSMIPv6 home link detection if not already performedthrough the 3GPP access system 1405 ₁ (1608).

The WTRU 1420 may then send a BU (HoA, CoA, Lifetime, BID, FID, flowdescription) message to the HA 1407 (1610) over the untrusted non-3GPPaccess system 1405 ₃, or alternatively, the 3GPP access system 14051.This BU (HoA, CoA, Lifetime, BID, FID, flow description) may include thefirst binding 1502 and the second binding 1504. As noted above, thefirst binding 1502 may include the HoA1, CoA1, BID 1, FID1 and firstrouting rule for the first flow registration 1506. The first binding1502 may include the HoA1, CoA1, BID 1, FID2 and second routing rule forthe second flow registration 1506. The second binding may include theHoA1, CoA2, BID 2, FID3 and third routing rule for the third flowregistration. The BU (HoA, CoA, Lifetime, BID, FID, flow description)message may also include an indication indicating simultaneousconnection over the untrusted non-3GPP access system 1405 ₃ and the 3GPPaccess system 1405 ₁.

The PGW 1466 may send an IP Connectivity Access Network (“IP-CAN”)session modification request to the PCRF 1420 (1612). In this request,the PGW 1466 may provide updated routing rules to the PCRF 1420. ThePCRF 1420 may store the first and second bindings 1502, 1504 including,for example, a mapping between the flow registrations 1506, 1508 and1510 and respective routing addresses CoA1, CoA1 and CoA2.

Based on the successful establishment of resources, the PCRF 1420 maysend an IP-CAN session modification response message to the PGW 1466with an acknowledgement of the IP-CAN session modification requestmessage (1614). The IP-CAN session modification response may includeupdated PCC rules, if appropriate. The PGW 1466 may pass the updatedrouting rules to the HA 1407.

The HA 1407 may create the first and second bindings 1502, 1504, andinstall the first, second and third IP flow routing filters. The HA 1407may then send a BA (Lifetime, HoA, CoA, BID, FID) message to indicatethe first, second and third routing filters are accepted (1616).

Based on the IP-CAN session modification request (1612), the PCRF 1420may ensure that the relevant QoS rules for the first, second and thirdflows are installed in a target bearer binding and event reportingfunction (“BBERF”). This may be done by a GW control session and QoSrules provision procedure (1618).

FIG. 17 is a message flow diagram illustrating an example of a process1700 for performing wtru-initiated IFOM. The process 1700 is describedwith reference to the communications system 1400 of FIGS. 14A-14B andthe flow table 1500 of FIG. 15B. In this process 1700, a new routingrule may be activated and/or an existing routing rule may modified bythe WTRU 1402 moving one traffic flow from one access to another access,e.g., moving the first flow from the 3GPP access system 1403 ₁ to theuntrusted non-3GPP access system 1405 ₃.

The WTRU 1402 may be simultaneously connected to the 3GPP access system1405 ₁ to the untrusted non-3GPP access system 1403 ₃ (1702). The WTRU1420 may send a BU (HoA, BID, FID) message to the HA 1407 (1704) toinstall the new routing rule for the first flow or, alternatively,modify the routing address of the first routing rule to route the firstflow (identified by the FID) through the untrusted non-3GPP accesssystem 1405 ₃ (identified by the included BID) or to remove the firstrouting rule from the first binding 1502.

For the new routing rule, the WTRU 1402 may include the routing filterdescription. The WTRU 1402 may send the BU (HoA, BID, FID) via eitherthe 3GPP access system 1405 ₁ or the untrusted non-3GPP access system1405 ₃.

The PGW 1466 may send an IP-CAN session modification request messagewith the updated routing rules to the PCRF 1420 (1706). The PCRF 1420may process the updated routing rules from the IP-CAN sessionmodification request message, and then store the updated routing rulesin an updated mapping.

Based on the successful establishment of resources in the untrustednon-3GPP access system 1405 ₃, the PCRF 1420 may send an IP-CAN sessionmodification response message to the PGW 1466 with an acknowledgement ofthe IP-CAN session modification request message (1708). The IP-CANsession modification response may include updated PCC rules, ifappropriate. The PGW 1466 may pass the updated routing rules to the HA1407.

The HA 1407, in turn, may send to the WTRU 1402 a BA (lifetime, HoA,BID, FID) message (1710) so as to signal to the WTRU 1420 acceptance ofthe updated routing rules. The HA 1407 may then send the BA (lifetime,HoA, BID, FID) message to the PCRF 1420 (1710). In some instances, theHA 1407 may send the BA message prior to the PGW 1466 receiving from thePCRF 1420 a reply to the IP-CAN session modification request message.

Based on the IP-CAN session modification request, the PCRF 1420 mayensure that relevant quality of service (“QoS”) rules are installed inthe target access system or relevant QoS rules are uninstalled from thesource access system. For non-3GPP access systems (trusted oruntrusted), this may be performed by a GW control session and QoS rulesprovision procedure (1712). Appropriate EPS resource release proceduresmay be executed for resources that were moved away from the 3GPP accesssystem 1405 ₁ or appropriate EPS resource allocation procedures areexecuted for those resources that were moved to the 3GPP access system1405 ₁ (1714).

FIGS. 18-25 are message flow diagrams illustrating respective examplesof processes 1800-2500 for performing IFOM across multiple accesstechnologies. Each of the processes 1800-2500 is described withreference to the communications system 1400 of FIG. 14. The processes1800-2500 may be carried out using other architectures, as well. Whereapplicable, reference may be made between and/or among the processes1800-2500 or elements thereof.

Referring to FIG. 18, a procedure (1802) for establishing amultiple-access PDN connection and for the first and second bindings1502, 1504 along with first, second and third flow bindings 1506, 1508,1510 at the HA 1407 (1802) is carried out, as, for example, using theprocess 1600 of FIG. 16. The procedure 1802 may be carried out in otherways as well.

The NMCF 1424 may be continually collecting and monitoring the localradio and backhaul metrics for the flow-updating events. Collection ofthe local radio and backhaul metrics may be carried out in real time, innear real time, at a given frequency, etc. While collecting andmonitoring the local radio and backhaul metrics, NMCF 1424 may detect aflow-updating event (1804). After detecting the flow-updating event, theNMCF 1424 may determine that a reassignment of the third IP flow fromthe untrusted non-3GPP access system 1405 ₃ to the 3GPP access system1405 ₁ may be warranted. To facilitate such reassignment, the NMCF 1424may query the PCRF 1420 to obtain the second flow binding 1504. The NMCF1424 may then generate a service data flow (“SDF”) change request. TheSDF change request may include the HoA1, CoA1, BID1, FID3 and the thirdrouting filter. The SDF change request may include other information, aswell.

After generating the SDF change request, the NMCF 1424 may populate itinto an IP CAN session modification request message. The NMCF 1424 maythereafter send the IP CAN session modification request to the PCRF 1420(1806).

The PCRF 1420, in turn, may process the SDF change request from the IPCAN session modification request message, and then relay the SDF changerequest unchanged to the PGW 1466 in another IP CAN session modificationrequest message (1808). Alternatively, the PCRF 1420 may modify the SDFchange request before sending the IP CAN session modification message tothe PGW 1466. The PCRF 1420 may modify the SDF change request, forexample, to handle differences in the interface between the PCRF 1420and PGW 1466 and the interface between the PCRF 1420 and NMCF 1424.Alternatively, the PCRF 1420 may modify the SDF change request to formatit for the HA 1407.

Responsive to the IP CAN session modification request message, the PGW1466 may send to the PCRF 1420 an IP CAN session modification responsemessage populated with a response acknowledging receipt of the request(1810). The response may include other information, as well. The PGW1466 may also process the SDF change request from the IP CAN sessionmodification message, and then pass the SDF change request to the HA1407. The HA 1407, in turn, may process the SDF change request to obtainthe HoA1, CoA1, BID1, FID3 and the third routing filter. Thereafter, theHA 1407 may populate the HoA1, CoA1, BID1, FID3 and the third routingfilter into a BU (HoA, CoA, BID, FID and the routing filter) message,and send the BU message to the WTRU 1402 (1812).

Responsive to the BU message, the WTRU 1402 may process the HoA, CoA,BID, FID and the third routing filter from the BU (HoA, CoA, BID, FIDand the routing filter) message, and decide to accept the BU request forthe IP flow as signaled by the BU message. The WTRU 1402 may then updatethe WTRU binding list in accordance with the BU request by associatingthe FID3 and routing filter 3 with the BID1, and de-associating the FID3and routing filter 3 from the BID2.

Additionally, the WTRU 1402 may populate the HoA1, CoA1, BID1, FID3 andthe third routing filter into a BA (HoA, CoA, BID, FID and the routingfilter) message, and then send the BA message to the HA 1407 (1814).Receipt of the BA message at the HA 1407 may signal to the HA 1407 anacknowledgement of receipt of the BU message at the WTRU 1402, andinclusion of the CoA1, BID1, FID3 may signal to the HA 1407 anacceptance of the BU (HoA, CoA, BID, FID and the routing filter) requestby the WTRU 1402. Responsive to the acceptance of the BU (HoA, CoA, BID,FID and the routing filter) request, the HA 1407 may update the HAbinding cache in accordance with the BU request by associating the FID3and routing filter 3 with the BID1, and de-associating the FID3 androuting filter 2 from the BID2.

An EPS resource release or EPS bearer setup or modification proceduremay be performed responsive to and in accordance with the accepted BUrequest (1816). Although not shown in FIG. 1800, the NMCF 1424 may sendthe SDF change request (in, for example, an IP CAN session modificationrequest message) to the PGW 1466. The PGW 1466, in turn, may populatethe SDF change request into an IP CAN session modification requestmessage, and send such message to the PCRF 1420. The PGW 1466 may sendthe SDF change request to the PCRF 1420 using other types of signalingmessages, as well.

FIG. 19 is a message-flow diagram illustrating an example of a process1900 for network-initiated IFOM across multiple access technologies. Theprocess 1900 of FIG. 19 is similar to the process 1800 of FIG. 18,except as described herein below. To facilitate the process 1900, thePCRF 1420 may be configured with capabilities to process and make flowmobility decisions based the link and network status information sentfrom the NMCF 1424. Additionally and/or alternatively, the NMCF 1424 maybe replaced with another entity (not shown) having monitoringfunctionality of the NMCF 1424, without the flow mobility decisionmaking functionality.

The NMCF 1424 may be continually collecting the local radio and backhaulmetrics. While collecting, the NMCF 1424 may send the local radio andbackhaul metrics to the PCRF 1420 (1902). The NMCF 1424 may send thelocal radio and backhaul metrics to the PCRF 1420 over any suitableinterval, including, for example, in real time, in near real time, at agiven frequency, etc.

The PCRF 1420 may monitor the local radio and backhaul metrics for flowupdating events. After detecting a flow updating event (1904), the PCRF1420 may determine that a reassignment of the first IP flow from the3GPP access system 14051 to the untrusted non-3GPP access system 14053may be warranted. The PCRF 1420 may then generate a SDF change requestwith the first binding 1502 for the first registered flow, FID1. The SDFchange request may include the HoA1, CoA2, BID2, FID1 and the firstrouting filter. The SDF change request may include other information, aswell.

After generating the SDF change request, the PCRF 1420 may populate theSDF request into a IP CAN session modification message, send the IP CANsession modification message to the HA 1407 (1808). Thereafter theprocess 1900 may continue as described with respect to the process 1800of FIG. 18 starting from (1810).

FIG. 20 is a message-flow diagram illustrating an example of a process2000 for performing IFOM across multiple access technologies. Theprocess 2000 of FIG. 20 is similar to the process 1800 of FIG. 18,except as described herein below.

The process 2000 may be used to resolve and/or avert potentialcollisions between a BU message initiated by the HA 1407 (“nw-initiatedBU message”) and a BU message initiated by the WTRU 1402(“wtru-initiated BU message”). To facilitate the process 2000, the HA1407 and WTRU 1402 are provisioned with respective priorities(“ha-priority” and “wtru-priority”, respectively); one being subordinateto the other. The HA 1407 and WTRU 1402 may refer to these priorities toresolve a potential collision between nw-initiated and wtru-initiated BUmessages. The provisioning of the ha-priority and wtru-priority with HA1407 and WTRU 1402 may be carried out, for example, as described abovewith respect to process 600 of FIG. 6. Provisioning of the ha-priorityand wtru-priority may be carried out in other ways, as well.

The HA 1407 may receive a wtru-initiated BU message from the WTRU 1402(2002) after sending the nw-initiated BU message to the WTRU 1402 (1812)and while awaiting a response to such nw-initiated BU message.Responsive to the wtru-initiated BU message, the HA 1407 may refer tothe ha-priority and the wtru-priority, and then apply the ha-priorityand the wtru-priority to priority rules (2004). After determining theha-priority is subordinate to the wtru-priority, the HA 1407 may send tothe WTRU 1402 a BA message configured to acknowledge and accept thewtru-initiated BU message (2006). Additionally, the WTRU 1402 maydiscard the nw-initiated BU message, and the HA 1407 may abandon thenw-initiated BU message.

The process 2000 may be also carried out when the WTRU 1402 receives thenw-initiated BU message from the HA 1407 (1812) after sending thewtru-initiated BU message to the WTRU 1402 (1812) and while awaiting aresponse to the wtru-initiated BU message. For example, after receivingthe nw-initiated BU message, the WTRU 1402 may refer to the ha-priorityand the wtru-priority, and apply the ha-priority and the wtru-priorityto the priority rules (2008). Responsive to determining thewtru-priority is subordinate to the ha-priority, the WTRU 1402 may sendto the HA 1407 a BA message configured to acknowledge and accept theha-initiated BU message (2010). The HA 1407 may discard the nw-initiatedBU message, and the WTRU 1402 may abandon the nw-initiated BU message.

Although not shown in FIG. 20, if, after determining the wtru-priority(or ha-priority) is subordinate to the ha-priority (or wtru-priority),the HA 1407 (or WTRU 1402) may reject the wtru-initiated (ornw-initiated) BU message, and send to the WTRU 1402 (or HA 1407) a BAmessage specifying an error code for rejecting the wtru-initiated (ornw-initiated) BU message (e.g. “collision-lower priority”).Alternatively, the HA 1407 (or WTRU 1402) may resend the nw-initiated(or wtru-initiated) BU request (or another nw-initiated (orwtru-initiated) BU request).

As another alternative, the WTRU 1402 (or HA 1407) may include anoverriding priority indicator in the wtru-initiated (or nw-initiated) BUmessage. In response to the overriding priority indicator, the HA 1407(or WTRU 1402) may over ride (e.g., not consider) ha-priority and thewtru-priority, and instead, determine the wtru-initiated (ornw-initiated) BU message takes precedence over the nw-initiated (orwtru-initiated) BU message. The HA 1407 (or WTRU 1402) may then send tothe WTRU 1402 (or HA 1407) a BA message configured to acknowledge andaccept the wtru-initiated (or nw-initiated) BU message.

In yet another alternative, the HA 1407 and the WTRU 1402 may refer topriority indicators associated with any of the first, second and thirdrouting filters in the HA binding cache and WTRU binding list (e.g., asrepresented in flow table 1500) to determine whether any of the first,second and third routing filters may be modified. The priorityindicators may be populated into the HA binding cache and WTRU bindinglist during an assignment of the IP flows. The priority indicators maybe part of the routing filters description and/or may be maintained in aseparate entry of the HA binding cache and WTRU binding list. Thepriority indicators may be maintained in other parts of the HA bindingcache and WTRU binding lists. For example, the priority indicators maybe defined as part of the FIDs. The priority indication may prevent theHA 1407 from sending an nw-initiated BU message when the priorityindicator indicates the WTRU 1402 has priority over the HA 1407.Conversely, the priority indication may prevent the WTRU 1402 fromsending a wtru-initiated BU message when the priority indicatorindicates the HA 1407 has priority over the WTRU 1402.

Alternatively, before the HA 1407 and/or the WTRU 1402 initiate BUmessages, the HA 1407 and/or the WTRU 1402 may refer to a timeout valueassociated with a selected routing filter in the HA binding cache andWTRU binding list (e.g., as represented in flow table 1500) to determinea time after which the routing filter can be modified. For example, acondition with the network 1403 may warrant the HA 1407 movement of thefirst flow from the 3GPP access system 1405 ₁ to the untrusted non-3GPPaccess system 1405 ₃. Prior to the HA 1407 sending a nw-initiated BUmessage to initiate the move, the HA 1407 may refer to the HA bindingcache for a timeout value for the first routing filter, whereupon the HA1407 may be informed that the timeout value has not expired and the HA1407 may prohibited from sending the nw-initiated BU message for thefirst routing filter until expiry of such timeout value.

The timeout value(s) may be added to the HA binding cache and WTRUbinding list during assignment of the IP flow. The timeout value(s) maybe part of the routing filters description and/or may be maintained in aseparate entry of the HA binding cache and WTRU binding list.Alternatively, the timeout value(s) may be maintained in other parts ofthe HA binding cache and WTRU binding lists, such as, for example, theFID(s).

FIG. 21 is a message-flow diagram illustrating an example of a process2100 for performing IFOM across multiple access technologies. Theprocess 2100 of FIG. 21 is similar to the process 1800 of FIG. 18,except as described herein below.

After receiving the nw-initiated BU request from the HA 1407 (1812), theWTRU 1402 may send to the HA 1407 a Rej-BU message with cause values tosignal to the HA 1407 a rejection of the nw-initiated BU request and toprovide one or more causes for the rejection (2102). The cause valuesinclude values to indicate that the rejection was due to (e.g.,suboptimal) local radio conditions with for access system requested inthe BU message, battery conditions and the like. The cause values mayindicate other causes for the rejection, as well.

FIG. 22 is a message-flow diagram illustrating an example of a process2200 for performing IFOM across multiple access technologies. Theprocess 2200 of FIG. 22 is similar to the process 1800 of FIG. 18,except as described herein below.

The process 2200 may be useful for the HA 1407 and the WTRU 1402 tonegotiate various for flow mobility operations, including flow splittingoperations. To facilitate the negotiations, the HA 1407 and/or the WTRU1402 may use a binding update ID (“BUID”) to track the modificationsrequests. For example, the HA 1407 may initiate the negotiation bypopulating a BUID into a BU message to form, for example, a BU (HoA,BID, FID, BUID) message. Thereafter the HA 1407 may send the BU (HoA,BID, FID, BUID) message to the WTRU 1402 (2202).

The WTRU 1402 may respond to the BU (HoA, BID, FID, BUID) message with arequest to modify one or more parameters of the BU (HoA, BID, FID, BUID)message. The WTRU 1402 may send the request by populating a Mod-BUmessage with the requested parameter and the BUID so as to form a Mod-BU(HoA, BID, FID, BUID) message (2204).

The HA 1407 may then make the requested changes of the parameters of theBU message, populate a BU message with the requested changes and asecond BUID so as to form a BU (HoA, BID, FID, BUID+1) message, and thensend a BU (HoA, BID, FID, BUID+1) message to the WTRU 1402 (2206). TheWTRU 1402 may respond with a BA message populated with the BUID+1(2208).

As shown, the BUID may be incremented to track the modificationrequests. The BUID may be a function other than incrementing by one, aswell. Additionally, the HA 1407 and the WTRU 1402 may use the process2200 to negotiate parameters including alternative suggestions for flowsplitting operations. For example, if the BU (HoA, BID, FID, BUID)message suggests a 50-50 split in a single flow across two interfaces,then the WTRU 1204 may respond back with a suggestion that 30-70 splitmay be preferred. Alternatively, the WTRU 1204 may respond with a Mod-BUmessage that indicates that the flow to be moved cannot be sustained bythe new radio link, but only a fraction of that flow may be supportable.

The BUID may be used in all BU-BA-like message exchanges. Using the BUIDmay help identify a particular BU message in consideration (e.g., when aBU message does not evoke a BA message). For example, the when both theWTRU 1402 and HA 1407 use BUIDs, a BU message under consideration may beresolved using the BUIDs.

FIG. 23 is a message flow diagram illustrating an example process forperforming IFOM over multiple access technologies. The process 2300 ofFIG. 23 is similar to the process 1800 of FIG. 18, except as describedherein below.

Each of the WTRU 1402, an eNB 1404 ₁ and/or AP 1404 ₃ may provide radionetwork related information to the ANDSF 1422 (2302). The ANDSF 1422 maycollect such information and process and pass it to the NMCF 1424 formaking decisions regarding flow mobility, etc. In one embodiment,functionality of the NMCF 1424 may be integrated with the ANDSF 1422.

FIG. 24 is a message flow diagram illustrating an example of a process2400 for performing IFOM over multiple access technologies. The process2400 may be used to resolve and/or avert potential collisions between annw-initiated BU message and a wtru-initiated BU message. To facilitatethe process 240, a token, whose possession is required to initiate a BUmessage, may be made available to the HA 1407 and to the WTRU 1402. Thetoken may be maintained by either the HA 1407 or the WTRU 1402 bydefault, and returned when not being used. Alternatively, a networkentity of the network 1403 may maintain the token, and issue it to theHA 1407 or the WTRU 1402 on request. As another alternative, an instanceof the token may be generated when another instance is not in use. Thetoken instance may expire after use or other event (e.g., a given timeperiod). For simplicity of exposition, the process 2300 assumes the WTRU1402 possesses the token by default.

Given the token is possessed by the WTRU 1402, the WTRU may send a BUmessage to the HA 1407 (2402). The HA 1407 may respond with a BA message(2404). The HA 1407 may send to the WTRU 1402 a token-request message.The token-request message may be sent over the multi-access PDNconnection or, alternatively, over another connection with the WTRU 1402(2406). Responsive to the token-request message, the WTRU 1402 may sendthe token to the HA 1407 (2408). After obtaining the token, the HA 1407may send to the WTRU 1402 an nw-initiated BU message (2412). The HA 1407may receive from the WTRU 1402 a BA message acknowledging thenw-initiated BU message (2414).

FIG. 25 is a message flow diagram illustrating an example of a process2500 for performing IFOM over multiple access technologies. The process2500 may be used to resolve and/or avert potential collisions between annw-initiated BU message and a wtru-initiated BU message.

The WTRU 1402 may send a wtru-initiated BU message (2502). The HA 1407may initiate an nw-initiated BU message (2504) while the wtru-initiatedBU message is in transit towards the HA 1407, but has not reached the HA1407. When the wtru-initiated BU message arrives at the HA 1407, the HA1407 detects a collision and decides on either accepting thewtru-initiated BU message or insisting on the nw-initiated BU message(2506). The HA 1407 may decide to accept the wtru-initiated BU message,and responsively, sends a BA message to the WTRU 1407 (2508).

The WTRU 1402 may receive the nw-initiated BU message, and detects theBU collision. The WTRU 1402 may then make a decision to either acceptthe nw-initiated BU message or insist on the wtru-initiated BU message.The WTRU 1402 may decide to accept the wtru-initiated BU message, andsends a BA message to the HA 1407.

The BA message may be received by the HA 1407. The HA 1407 maythereafter determine that the WTRU 1402 wants to keep the nw-initiatedBU message, whereas it wanted to keep the wtru-initiated BU message,causing a conflict. Responsively, the HA 1407 may make a decision whichBU message to keep (2514) and include the selected BU message in a BCmessage (2516).

FIG. 26 is a block diagram illustrating an example of a communicationssystem 2600 for performing bandwidth management (“BWM”). Thecommunications system 2600 may include a home area network (“HAN”) orenterprise area network (“EAN”) (hereinafter HAN/EAN) 2605, a publicinternet 2610, an MCN 2615, a digital subscriber line (“DSL”) (i.e.,broadband) modem 2620, an outer domain name system (“DNS”) server 2625,an initial SeGW 2630 and a serving SeGW 2635.

The DSL modem 2620 may include a DNS server 2638 for resolving domainnames to IP addresses, and a dynamic host configuration protocol(“DHCP”) server 2640 for assigning dynamic IP addresses. The HAN/EAN2605 may include a WTRU having a BWM application 2642 that may run overand a local IWLAN (“L-IWLAN”) client 2644 (e.g., a DSMIP based client).The HAN/EAN 2605 may also include an HNB 2646, a Wi-Fi AP connected toan AR (collectively “AP/AR”) 2650, a local HA (“L-HA”) 2607 and a localgateway (“LGW”) 2648 (e.g., a local variant of a GGSN).

The MCN 2615 may include an initial home Node-B management system(“HMS”) 2660, a serving HMS 2662, a GGSN 2664, a HNB GW 2666, an SGSN2668 and an inner DNS server 2670. The outer DNS server 2625 and theinner DNS server 2670 may serve similar functions within the publicinternet 2610 and the MCN 2615, respectively. The initial serving SeGW930 and the serving SeGW 935 may serve as security gateways.

A local IP access (“LIPA”) or other local IP (collectively “local IP”)connection may be set up, with direct tunnel establishment between anHNB 946 and an LGW 948. This may be implemented by a WTRU 2602 sending aPDP context request along with an access point name (“APN”) to the SGSN968, which resolves the APN to identify the LGW 948 (as a local GGSN)for the WTRU 2602 to connect to. Thereafter a direct tunnel between theHNB 946 and the LGW 948 may be established, bypassing the SGSN 968 (datapath).

An IP connection may then be set up between the LGW 948 and the GGSN 964of the MCN 2615 on the Gi interface. The WTRU 2702 may register with theL-HA 2707 using DSMIP procedures (e.g., as described in processes1600-1800 of FIGS. 16-18 above). A Wi-Fi radio link may be set up bysending a BU message to the L-HA 2707 over an H1 interface (e.g., asdescribed in processes 1600-1800 of FIGS. 16-18 above). The cellular andWi-Fi links may be managed by sending BU and/or other DSMIP signalingmessages between the WTRU 2702 and the L-HA 2707 (e.g., as described inprocesses 1600-2500 of FIGS. 16-25 above).

Alternatively, a split GTP tunnel may be set up between a WTRU 2702 andthe SGSN 2668 via the L-HA 2707. The WTRU 2702 may be registered withthe L-HA 2707 using DSMIP procedures (e.g., as described in processes1600-1800 of FIGS. 16-18 above). A Wi-Fi radio link may also be set upand added by sending (e.g., a BU) message to the L-HA 2707 over an H1interface. The cellular and Wi-Fi links may be managed by sending BUand/or other DSMIP signaling messages between the WTRU 2702 and the L-HA2707 (e.g., as described in processes 1600-2500 of FIGS. 16-25 above).

Other processes may provide (e.g., BWM) control over movement ofIP-flows and IP-sub flows among the various RATs of the communicationssystems disclosed herein. The BWM control may be provided by the WTRU orby the network. The BWM control may be performed at service level or at(network) policy level. Service-level application programming interfaces(APIs) may be used. Alternatively, network-level APIs and policyenforcing entities such as a PCRF of a MCN 2615 may be implemented.Additionally and/or alternatively, a single IP flow may be split intomultiple IP sub flows, which may be transported over multiplesimultaneous connections.

In one embodiment, IP flow splitting may be performed over the multipleaccess system of the communication system 2600. To facilitate the IPflow splitting, a multilink point-to-point protocol (PPP) may beimplemented. In one embodiment, each IP-flow (or IP-sub flow) may bedefined as a set of rules defining a routing filter in a binding cacheand/or binding list, such as, for example, represented in the flow table1500 of FIG. 15B.

The IP flow may be split, for example, into two IP sub-flows, with theIP sub-flows being defined alternating or other by a rule defining thedistribution of the IP packets. Each of the IP sub-flows (as shown,e.g., in flow table 1500 as first and second (sub)flows 1506, 1510) maybe defined by respective routing filters, and these filters may carry anencoded version of the rules, which may be processed by an L-HA 2652 toappropriately route the first and second sub flows 1506, 1510 to theCoA1 and CoA2.

FIGS. 27A-27K are block diagrams illustrating examples of communicationssystems 2700A-2700K in which one or more disclosed embodiments may beimplemented and/or carried out. Any of the communications systems2700A-2700K may be implemented as the HAN/EAN 2605 of FIG. 26. Forsimplicity of exposition, the communications systems 2700A-2700F aredescribed with reference to the communication system 2600 of FIG. 26.The communications systems 2700A-2700K may be implemented in othercommunications systems, as well.

Referring to FIG. 27A, the communications system 2700A may define, forexample, a femtocell and LGW-based I-WLAN architecture. Thecommunications system 2700A may include a WTRU 2702, a HNB 2710, a LGW2715, a Wi-Fi AP/AR 2720, an L-HA 2707 and a local WAG combined with alocal PDG (collectively “WAG/PDG”) 2735.

The WTRU 2702 may terminate cellular radio links to the HNB 2710 andWi-Fi radio links with the Wi-Fi AP/AR 2720. The HNB 2710 may connect tothe LGW 2715. The Wi-Fi AP/AR 2720 may connect to the local WAG/PDG2735.

The Wi-Fi AP/AR 2720 and the local WAG/PDG 2735 may output IP packets,which may be transported to the L-HA 2707 via H3 interfaces. The L-HA2707 may provide protocol conversion from IP to Iuh towards an MCN 2730.The L-HA 2707 may optionally support deep packet inspection (“DPI”)capabilities to assist in steering of IP packets across the cellular andWi-Fi links. The L-HA 2707 may also manage aggregation of IP flows from(i) the HNB 2710 and the LGW 2715, and (ii) the Wi-Fi AP/AR 2720 and thelocal WAG/PDG 2735. The HA 2707 may support mobility of IP flows overthe cellular and Wi-Fi links, as well.

The L-HA 2707 may use the I-WLAN protocols, suitably modified for localapplication. Combined IP flows from the L-HA 2707 may be transported tothe SeGW 2635 of the MCN 2615 via GTP tunnels, which may be securedwithin an IPSec tunnel. The physical medium may be the broadband linkfrom the L-HA 2707 to the MCN 2615. The L-HA 2707 may encapsulate IPpackets on the H1 interface to GTP packets on the Iuh interface, andvice versa. The L-HA 2707 may be controlled by an SGSN signaling planeof the MCN 2615.

Referring now to FIG. 27B, a block diagram illustrating an example ofthe communications system 2700B is shown. The communications system2700B may define, for example, a femtocell-based I-WLAN architecture.The communications system 2700B is similar to the communications system2700A of FIG. 27A, except that the HNB 2710 may directly connect to theL-HA 2707 via an Iuh interface without using an LGW.

FIG. 27C is a block diagram illustrating an example of thecommunications system 2700C. The communications system 2700C may define,for example, a LGW-based I-WLAN architecture. The communications system2700C is similar to the communications system 2700A of FIG. 27A, exceptthat the Wi-Fi AP/AR 2720, as a trusted entity of the L-HA 2707, maydirectly connect to the L-HA 2707 via an H3 interface (e.g., withoutusing a local WAG/PDG).

FIG. 27D is a block diagram illustrating an example of thecommunications system 2700D. The communications system 2700D may definea joint implementation of an LGW and L-HA (“LGW/L-HA”) 2735 in an I-WLANarchitecture. The LGW/L-HA 2735 may communicate with the WTRU 2702 viaan H1 interface, with an HNB 2710 via a GTP interface, and with a Wi-FiAP/AR 2720 via an H3 interface. The LGW/L-HA 2735 may also communicatewith the MCN 2730 via an Iuh interface. The H3 interface may carry IPpackets between the Wi-Fi AP/AR 2720 and LGW/L-HA 2735. The GTPinterface may carry IP packets the HNB 2710 and the LGW/L-HA 2735. TheWTRU 2702 and the L-HA 2707 may exchange signaling and user datatransfer via the H3 interface (e.g., transported over IP connectivityprovided by IWLAN or 3GPP access system). The Iuh interface maytransport IP packets via GTP tunnels with the MCN 2615.

Referring now to FIG. 27E, a block diagram illustrating an example ofthe communications system 2700E is shown. The communications system2700E may define an IWLAN architecture configured to bypass the SGSN2668 of the MCN 2615. The communications system 2700E is similar to thecommunications system 2700D of FIG. 27D, except as described herein.

The LGW/L-HA 2735 may support a Gi interface to and operate as a Giproxy for the GGSN 2664 in the MCN 2615. A packet data connection fromthe WTRU 2702 may terminate at the LGW/L-HA 2735 via a direct tunnelbetween the HNB 2710 and LGW/L-HA 2735. An IP connection may beestablished between the LGW/L-HA 2735 and GGSN 2664 through an IPSectunnel between the LGW/L-HA 2735 and the SeGW 2635 of the MCN 2615.

Although not shown the FIGS. 27A-27E, SGSN functionality may beimplemented within the HAN/EAN domains, for example, with in the variousembodiments of the LGW. A LGW with SGSN functionality may limit, forexample, user mobility related signaling traffic traverse the MCN 2615and permit user mobility management within a large enterpriseenvironment a LGW/LHA may manage multiple HNBs.

FIG. 27F is a block diagram illustrating an example of thecommunications system 2700F. The communications system 2700F may definean unlicensed mobile access (“UMA”)-based femtocell BWM architecture.UMA or generic access network (“GAN”) refers to 3GPP standardizedsolutions for accessing a cellular core network using unlicensed access,such as by a WLAN. The Wi-Fi AP/AR 2720 may access an MCN 2615 via a UMAor GAN controller 2750.

Although each of the communications systems 2700A-2700F as shown theFIGS. 27A-27E assume the MCN 2615 having a UTMS architecture. Thecommunications systems 2700A-2700F may also be implemented with an MCNhaving an EPC architecture.

FIG. 27G is a block diagram illustrating an example of thecommunications system 2700F. The communications system 2700F may definea femtocell and LGW-based EPC architecture. The communications system2700F may include the WTRU 2702, a HeNB 2755, a LGW 2765, a Wi-Fi AP/AR2720, a L-HA 2707 and a local ePDG 2760.

The WTRU 2702 may terminate cellular radio links to the HeNB 2755 andWi-Fi radio links with the Wi-Fi AP/AR 2720. The HeNB 2755 may connectto the LGW 2765, (e.g., a local PGW). The Wi-Fi AP/AR 2720 may connectto the local ePDG 2760 as an untrusted access by the L-HA 2707. An IPSectunnel may be established between the WTRU 2702 and the local ePDG 2760over the SWu* reference point. (Standard reference points are annotatedwith an asterisk (*) to indicate possible adaptations for localvariants.)

The L-HA 2707 may provide protocol conversion from IP to S1 and/or S5interfaces towards an MCN 2730. The L-HA 2707 may manage the aggregationof the IP flows from the HeNB 2755 and the LGW 2765, and from the Wi-FiAP/AR 2720. The L-HA 2707 also may support mobility of IP flows betweenthe cellular and Wi-Fi links.

The L-HA 2707 may use EPC IP mobility protocols, suitably modified forlocal application. Combined IP flows from the L-HA 2707 may betransported to a SeGW of the MCN 2730 via GTP tunnels. These GTP tunnelsmay be secured within an IPSec tunnel.

FIG. 27H is a block diagram illustrating an example of thecommunications system 2700H is shown. The communications system 2700Hmay define, for example, a femtocell-based EPC architecture 2700H thatis similar to the communications system 2700G of FIG. 27G, except thatthere are no SWu or S2c interfaces, and the HeNB 2755 directly connectsto the L-HA 2707 via an IP interface without using an LGW.

FIG. 27I is a block diagram illustrating an example of thecommunications system 2700I. The communications system 2700I may define,for example, an LGW-based EPC architecture 2700I. The communicationssystem 2700I is similar to the communications system 2700G of FIG. 27G,except that the Wi-Fi AP/AR 2720 directly connects to the L-HA 2707 viaan IP interface without using a local ePDG. In addition, the Wi-Fiaccess is considered as “trusted” and a local ePDG/IPsec tunnel mightnot be required toward the WTRU 2702.

FIG. 27J is a block diagram illustrating an example of thecommunications system 2700J. The communications system 2700J may definea joint implementation LGW/L-HA 2735 in an EPC architecture. TheLGW/L-HA 2735 may communicate with the WTRU 2702 via an S2c interface,and with the HeNB 2755 and the Wi-Fi AP/AR 2720 via respective IPinterfaces. The LGW/L-HA 2735 may also communicate with the MCN 2730 viaS1 and S5 interfaces.

FIG. 27K is a block diagram illustrating an example of thecommunications system 2700K. The communications system 2700K may definean EPC architecture configured to bypass the SGW (not shown) of the MCN2730. The communications system 2700K is similar to the communicationssystem 2700J of FIG. 27J, except as described herein.

The LGW/L-HA 2735 may support a Gi interface to and operate as a Giproxy for a PGW 2770 in the MCN 2730. A packet data connection from theWTRU 2702 may terminate at the LGW/L-HA 2735 via a direct tunnel betweenthe HeNB 275 and LGW/L-HA 2735. An IP connection may be establishedbetween the LGW/L-HA 2735 and a PGW 2770 through an IPSec tunnel betweenthe LGW/L-HA 2735 and the SeGW of the MCN 2730.

Although not shown the FIGS. 27G-27K, the SGW of the MCN 2730 may bemoved to the HAN/EAN domains. This may may allow the HeNB 2755 and SGWto communicate without a direct tunnel, and may support implementationof alternatives for remote IP address (“RIPA”), local IP access (“LIPA”)and selective IP traffic offloading (“SIPTO”) connections.

In one embodiment, all three types of connections, RIPA, LIPA and SIPTO,traverse via the LGW. LGW may connect to the PGW 2770 using a SGiinterface into the internet, and may operate as a SGi Proxy for RIPA. Inone embodiment, the LIPA and SIPTO connections traverse via the LGW, andthe RIPA traffic traverse via a local SGW.

Referring now to FIG. 28, a block diagram illustrating protocols thatmay be used to provide any of BMW, BWA and IFOM in a communicationssystem is shown. This communications system may be any of thecommunications systems disclosed herein as well as other applicablecommunications systems. For simplicity of exposition, the protocols ofFIG. 28 are described with reference to a communications system 2800including a WTRU 2802, a femtocell-based access point (“FAP”) 2810, aWi-Fi AP 2815, an LGW/L-HA entity 2820 and a server/peer 2825. The WTRU2805 and the server/peer 2825 may include respective TCP layers 2830.The WTRU 2802 and the LGW/L-HA entity 2820 may include a BWM protocollayer 2832 and a DSMIP protocol layer 2834.

The BWM protocol layer 2832 may add a BWM protocol header. The BWMprotocol header may include fields for defining the IP-flow, which maybe mapped in FIDs as shown in the flow table of FIG. 15B. In oneembodiment, the BWM protocol header may contain an FID, for instance. Inone embodiment, the BWM protocol header may also include a sequencenumber, which may be used to implement an in-sequence delivery andretransmission protocol between the client and server BWM protocollayers 2832. When the BWM protocol layer 2832 includes sequence numbers,the partitioning of the IP flow from upper layers by the BWM protocol2832 may be achieved in a “feed-forward” manner, (i.e., not having toinform the receiving BWM protocol 2832 about the specifics of thepartitioning), and thus with low latency, (as compared to the case wherea message sequence is involved regarding the partitioning). This mayenable the IP-flow partitioning to be performed in a highly dynamicmanner, (e.g., based on varying channel conditions on the access links).

The WTRU 2802, the FAP 2810, the Wi-Fi-AP 2815, the LGW/L-HA entity 2820and the server/peer 2825 may include IP layers 2836. The WTRU 2805 andthe FAP 2810 may also include a cellular layer 2838. The WTRU 1005 andthe Wi-Fi-AP 1015 may also include a Wi-Fi layer 2840. The FAP 2810, theWi-Fi AP 2815, the LGW/L-HA entity 2820 and the server/peer 2825 mayinclude layer 1 (L1) and layer 2 (L2).

In one embodiment, flow splitting may be performed at the applicationlayer. For example, it is known that file transfer protocols (FTPs) andhypertext transfer protocols (HTTPs) allow for fragmented delivery of alarge file, by including the start and end points of the file to bedelivered.

Referring to FIG. 15B, if a client wants to download a file of 1M bytes,an FTP client may send a request to an FTP server to download the first100K bytes with a certain port number, which may map to FID1. The FTPclient may send a second request to download the next 100K bytes viaCoA2, (which may map to FID3). The FTP server may separately andsimultaneously download these 100K byte segments to a multi-RAT FTPclient. Upon receiving the 200K bytes, the FTP client may request thatthe next segment (e.g., 200K bytes), be downloaded by partitioning thenext segment into N and M bytes across CoA1 and CoA2, where N and M maybe determined by the quality of the links estimated by the previoustransmission of 200K bytes, thus providing an adaptive scheme. The IPflow splitting techniques described above and the protocol architectureof FIG. 28 may be implemented for BW aggregation, as well.

FIG. 29 is a flow diagram illustrating an example of a procedure 2900that may be implemented in a system including a WTRU 2905, a trustednon-3GPP IP access network/PDG/ePDG 2910, a UTRAN/eUTRAN 2915, an HA/PDNGW 2920, an HSS/AAA 2925 and an hPCRF 2930. Multiple RAT connections maybe created by an I-WLAN (2935). The BWM protocol layer of the WTRU 2905may send an aggregation request to the BWM protocol layer of the HA/PDNGW 2920 (2940). A BWM protocol may then be configured at the WTRU 2905and the HA/PDN GW 2920 (2960), and a unidirectional data flow may beestablished using the BWM protocol and a multi-network transportprotocol (MNTP).

CONCLUSION

In one embodiment, a method may include selecting, from a PDN connectionformed through a plurality of access systems communicatively coupledwith a WTRU, an access system over which to transport a flow of internetprotocol (“IP”) traffic to and/or from the WTRU; and sending, to theWTRU, a request to associate the flow of IP traffic with the selectedaccess system.

In some embodiments, the method may further include associating, at anentity of the network, the flow of IP traffic with the selected accesssystem. In some embodiments, the associating the flow of IP traffic withthe selected access system may include associating, at an entity of thenetwork, the flow of IP traffic with the selected access systemresponsive to an acceptance of the request.

In some embodiments, the method may include receiving, from the WTRU, anacknowledgement to the request. In some embodiments, the acknowledgementmay include a rejection of the request. In some embodiments, theacknowledgement may include and/or be the acceptance of the request. Insome embodiments, the method may include inferring, at the networkentity, the acceptance of the request.

In some embodiments, sending the request to associate the flow of IPtraffic with the selected access system may include sending the requestto the WTRU via any of the plurality of access systems. In someembodiments, at least one access system of the plurality of accesssystems is configured in accordance with a protocol promulgated by anyof the third generation partnership project (“3GPP”), the Institute ofElectrical and Electronics Engineers (“IEEE”) and Internet EngineeringTask Force (“IETF”).

In some embodiments, sending the request may include sending the requestresponsive to an event. In some embodiments, selecting an access systemmay include selecting the access system responsive to an event. In someembodiments, sending the request and selecting an access system mayoccur responsive to an event.

In some embodiments, the method may further include monitoring thenetwork for the event. In some embodiments, the WTRU may communicativelycouple with the plurality of access systems via a respective pluralityof wireless links, and the method may further include monitoring any ofthe network and plurality of wireless links for the event. In someembodiments, monitoring any of the network and plurality of events mayinclude monitoring any of the network, plurality of access systems andplurality of wireless links for the event.

In some embodiments, the method may further include monitoring thenetwork for an event; generating a trigger responsive to detection ofthe event; and using the trigger to initiate any of selecting an accesssystem and sending a request.

In some embodiments, the event may be and/or include a conditionassociated with any of the network and PDN connection. In someembodiments, the condition may include a measure of congestion. In someembodiments, the condition may include a measure of congestion. In someembodiments, the condition may include any of (i) a first measure ofconnectivity between the first access system and WTRU, and (ii) a secondmeasure of connectivity between the second access system and WTRU. Insome embodiments, the first measure of connectivity may include a firstsignal strength of the first wireless link, and wherein the secondmeasure of connectivity may include a second signal strength of thesecond wireless link. In some embodiments, the first and second measuresof connectivity comprise a measurement received from the WTRU.

In some embodiments, the request may be and/or include a binding update(“BU”) message. In some embodiments, the BU message may include a homeaddress associated with the WTRU for the PDN connection, a care ofaddress associated with the WTRU, and a traffic selector associated withthe flow of traffic. In some embodiments, the acknowledgment may beand/or include a binding acknowledgement (“BA”) message. In someembodiments, the BA message may include the home address associated withthe WTRU for the PDN connection, the care of address associated with theWTRU, and the traffic selector associated with the flow of traffic.

In some embodiments, the request may be and/or include a BU message, theacknowledgment may be and/or include a binding reject (“Rej-BU”)message, and the Rej-BU message may include an indication of a reasonfor rejecting the BU message.

In some embodiments, the method may further include selecting, from thePDN connection, a second access system over which to transport the flowof IP traffic to and/or from the WTRU; and sending, to the WTRU, asecond request to (i) associate the flow of IP traffic to the secondselected access system, and (ii) de-associate the flow of IP trafficfrom the first selected access system. In some embodiments, the methodmay further include associating, at the network entity, the flow of IPtraffic with the second selected access system; and de-associating, atthe network entity, the flow of IP traffic from the first selectedaccess system.

In some embodiments, the method may further include receiving, from theWTRU, a second acknowledgement to the second request. In someembodiments, the second request may be and/or include a second BUmessage, and the second acknowledgement may be and/or include a secondBA message.

In some embodiments, the method may further include sending, to theWTRU, a second request to de-associate the flow of IP traffic and fromthe selected access system. In some embodiments, responsive toacceptance of the third request, de-associating, at the network entity,the flow of IP traffic from the selected access system.

In some embodiments, the method may further include awaiting a responseto the request sent to the WTRU; receiving, from the WTRU, a secondrequest to associate the flow of IP traffic with a second access systemof the plurality of access systems; and responsive to a priorityassociated with the first request being subordinate to a priorityassociated with the second request, sending, to the WTRU, an acceptanceof the second request.

In some embodiments, the method may further include awaiting a responseto the request sent to the WTRU; receiving, from the WTRU, a secondrequest to associate the flow of IP traffic with a second access systemof the plurality of access systems; and responsive to a priorityassociated with the second request being subordinate to a priorityassociated with the first request, sending, to the WTRU, the request toassociate the flow of IP traffic to the first selected access system.

In some embodiments, the method may further include awaiting a responseto the request sent to the WTRU; receiving, from the WTRU, a secondrequest to modify the first request; sending, to the WTRU, a thirdrequest comprising a modification to the first request; and receiving,in responsive to the third request, an acceptance of the third request.In some embodiments, the second request and the modification to thefirst request may be and/or include a request to associate the flow ofIP traffic with a second access system of the plurality of accesssystems.

40. In some embodiments, the method may further include obtaining, at anetwork entity prior to sending the request, a token whose possession isrequired to send the request to associate to the WTRU. In someembodiments, the method may further include receiving, from the WTRU, arequest for the token; and sending the token to the WTRU.

In some embodiments, the method may further include awaiting a responseto the request sent to the WTRU; receiving, from the WTRU at a networkentity of the network prior to receiving the response to the request, asecond request to associate the flow of IP data with a second accesssystem of the plurality of access systems; detecting, at the networkentity, a collision between the first and second requests; and sending,to the WTRU responsive to the collision, an acceptance of the secondrequest. In some embodiments, the method may further include receiving,from the WTRU in response to any of the second request and theacceptance of the request, an acceptance of the first request; andsending, to the WTRU in response to the acceptance of the secondrequest, a confirmation of the acceptance of the first request.

In some embodiments, the method may further include receiving, from theWTRU, a second request to associate the flow of IP data with a secondaccess system of the plurality of access systems; and sending, to theWTRU, an acceptance of the second request.

In some embodiments, the method may further include selecting, from thePDN connection, a second access system over which to transport asub-flow of the flow of IP traffic to, from or to and from the WTRU;ands ending, to the WTRU, a second request to (i) associate the sub-flowwith the second selected access system the second care-of address and(ii) de-associate such sub-flow from the first selected access system.In some embodiments, the method may further include associating, at thenetwork entity, the sub-flow with the second selected access system; andde-associating, at the network entity, the sub-flow from the firstselected access system. In some embodiments, the method may furtherinclude receiving, from the WTRU, a second acknowledgement to the secondrequest. In some embodiments, the second request may be and/or include asecond BU message. In some embodiments, the second acknowledgement maybe and/or include a second binding acknowledgement message. In someembodiments, the method may further include sending, to the WTRU,information for reordering of packets to facilitate reconstruction ofthe flow of traffic.

In one embodiment, a method may include selecting, from a PDN connectionformed via a plurality of access systems communicatively coupled with aWTRU, a first access system over which to transport a first sub-flow ofa flow of IP traffic to and/or from the WTRU; selecting, from the PDNconnection, a second access system over which to transport a secondsub-flow of the flow of IP traffic to and/or from the WTRU; sending, tothe WTRU, a request to associate the first sub-flow with the firstselected access system, and to associate the second sub-flow with thesecond selected access system.

In some embodiments, the method may further include receiving, from theWTRU, an acknowledgement to the request. In some embodiments, therequest may be and/or include a BU message, and the acknowledgement maybe and/or include a BA message.

In one embodiment, a method may include receiving, at a WTRU, a requestto associate a flow of IP traffic with an access system selected fortransport of the flow of IP traffic to and/or from the WTRU, wherein theaccess system is selected from a PDN connection formed through aplurality of access systems communicatively coupled with the WTRU.

In some embodiments, the method may further include associating, at theWTRU, the flow of IP traffic with the selected access system. In someembodiments, the method may further include sending, to an entity of thenetwork, an acknowledgement to the request. In some embodiments, theacknowledgement may be and/or include a rejection of the request. Insome embodiments, the acknowledgement may be and/or include anacceptance of the request. In some embodiments, receiving a request toassociate the flow of IP traffic with the selected access system mayinclude receiving the request via any of the plurality of accesssystems.

In some embodiments, the selected access system may be selectedresponsive to an event. In some embodiments, the event may be and/orinclude a condition associated with any of the network and PDNconnection.

In one embodiment, an apparatus may include memory adapted to storeexecutable instructions; a processor adapted to execute the executableinstructions to select, from a PDN connection formed through a pluralityof access systems communicatively coupled with a WTRU, an access systemover which to transport a flow of internet protocol (“IP”) traffic to,from or to and from the WTRU; and a transmitter adapted to send, to theWTRU, a request to associate the flow of IP traffic with the selectedaccess system. In some embodiments, the memory may be further adapted tostore, in association, an identifier of the flow of IP traffic with aparameter associated with the selected access system. In someembodiments, the apparatus may further include a receiver adapted toreceive, from the WTRU, an acknowledgement to the request. In someembodiments, the transmitter may be further adapted to send the requestto the WTRU via any of the plurality of access systems.

In some embodiments, the processor may be further adapted to execute theexecutable instructions to select the access system, and the transmittermay be further adapted to send the request responsive to an event.

In one embodiment, a system may include a mobility agent adapted to (i)participate in forming a PDN connection through a plurality of accesssystems communicatively coupled with a WTRU, and (ii) select, from theplurality of access systems responsive to an event, an access systemover which to transport a flow of IP traffic to and/or from the WTRU; anetwork monitor adapted to (i) monitor any of the network and PDNconnection for the event, and (ii) cause the mobility agent to benotified of a detection of the event; and a transmitter adapted to send,to the WTRU, a request to associate the flow of IP traffic with theselected access system.

In some embodiments, the network monitor may be further adapted tomonitor a plurality of wireless links, communicatively coupling the WTRUand plurality of access systems, for the event. In some embodiments, thesystem may further include a policy enforcement entity adapted to (i)receive, from the network monitor, a notification of a detection of anevent; and (ii) notify the mobility agent of the detection of an event,wherein the network monitor is further adapted to send the notificationto the policy enforcement entity. In some embodiments, the networkmonitor may be further adapted to (i) receive measurements from theWTRU, and (ii) monitor the measurements for the event.

In one embodiment, a method for performing BWM in a network comprisingfirst and second access systems configured in accordance with cellularand WLAN access technologies, respectively, is provided. The method mayinclude establishing a local IP (e.g., LIPA) connection via an accessnode of the first access system; establishing a direct tunnel betweenthe access node and a LGW of the first access system; and establishingan IP connection between the LGW and a gateway of a MCN.

In some embodiments, establishing the LIPA connection may includeestablishing a first wireless link with a WTRU, and registering the WTRUwith a L-HA in connection with the local IP connection; establishing asecond wireless link with a access node of the second access system;adding the second wireless link to the local IP connection; and managingthe first and second wireless links in connection with transport oftraffic over the local IP connection.

In some embodiments, the access node of the first access system may beand/or include a home Node-B, the gateway of the MCN comprises a GGSN ofthe MCN, the access node of the second access system may be and/orinclude a WLAN access point, wherein the first wireless link comprises acellular link, and the second wireless link may be and/or include a WLANradio link. In some embodiments, establishing the IP connection mayinclude establishing the IP connection between the LGW and the GGSN on aGi interface. In some embodiments, the method may further includesending a packet data protocol (PDP) context request and an APN to aSGSN of the MCN. In some embodiments, the direct tunnel may bypass theSGSN on a data plane.

In some embodiments, adding the second wireless link may include sendinga BU message to the L-HA. In some embodiments, sending the BU messagemay include sending the BU message to the L-HA over an H1 interface. Insome embodiments, managing the first and second wireless links comprisesany of (i) sending, from the L-HA to the WTRU, a BU message andreceiving, at the L-HA from the WTRU, a responsive BA message, and (ii)receiving, at the L-HA from the WTRU, a BU message and sending, from theL-HA to the WTRU, a responsive BA messages.

In one embodiment, a method for performing bandwidth management (“BWM”)in a network comprising first and second access systems configured inaccordance with cellular and WLAN access technologies, respectively, isdisclosed. The method may include establishing a first wireless linkbetween a WTRU and an access node of the first access system;establishing a PDN connection using a split tunnel established betweenthe WTRU and a SGSN of a MCN via a L-HA of the network; registering theWTRU with the L-HA in connection with the PDN connection; establishing asecond wireless link with a access node of the second access system;adding the second wireless link to the PDN connection; and managing thefirst and second wireless links in connection with transport of trafficover the PDN connection.

In some embodiments, the split tunnel may be and/or include a split GTPtunnel. In some embodiments, adding the second wireless link may includesending a BU message to the L-HA. In some embodiments, sending a bindingupdate message may include sending the BU message to the L-HA over an H1interface.

In one embodiment, an apparatus may be configured to perform the methodas in any of the foregoing BWM embodiments.

A system for performing BWM in a network comprising first and secondaccess systems configured in accordance with cellular and WLAN accesstechnologies, respectively, is disclosed. In one embodiment, the systemmay include a WTRU having a BWM application; a first access node of thefirst access system; a second access node of the second access system; aLGW of the network; a direct tunnel established between the secondaccess node and the LGW; a local IP (e.g., a LIPA) connectionestablished via the first access node and the second access node; afirst wireless link between the WTRU and the first access node; a secondwireless link between the WTRU and the second access node; an IPconnection established between the LGW and a gateway of a MCN; and aL-HA of the network adapted to (i) register the WTRU therewith inconnection with the local IP connection, and (ii) manage first andsecond wireless links.

In some embodiments, the system may further include a local WLAN accessgateway (“WAG”) in communication with the second access node and theL-HA. In some embodiments, the LGW and the L-HA may be formed as asingle entity. In some embodiments, the L-HA may be further adapted toprovide to the MCN any of ingress into and egress from the network.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element can be used alone or in any combination with theother features and elements. In addition, the methods described hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals (transmitted over wired or wireless connections) andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, cache memory, semiconductormemory devices, magnetic media such as internal hard disks and removabledisks, magneto-optical media, and optical media such as CD-ROM disks,and digital versatile disks (DVDs). A processor in association withsoftware may be used to implement a radio frequency transceiver for usein a WTRU, UE, terminal, base station, RNC, or any host computer.

Variations of the method, apparatus and system described above arepossible without departing from the scope of the invention. In view ofthe wide variety of embodiments that can be applied, it should beunderstood that the illustrated embodiments are exemplary only, andshould not be taken as limiting the scope of the following claims. Forinstance, in the exemplary embodiments described herein include handhelddevices, which may include or be utilized with any appropriate voltagesource, such as a battery and the like, providing any appropriatevoltage.

Moreover, in the embodiments described above, processing platforms,computing systems, controllers, and other devices containing processorsare noted. These devices may contain at least one Central ProcessingUnit (“CPU”) and memory. In accordance with the practices of personsskilled in the art of computer programming, reference to acts andsymbolic representations of operations or instructions may be performedby the various CPUs and memories. Such acts and operations orinstructions may be referred to as being “executed,” “computer executed”or “CPU executed.”

One of ordinary skill in the art will appreciate that the acts andsymbolically represented operations or instructions include themanipulation of electrical signals by the CPU. An electrical systemrepresents data bits that can cause a resulting transformation orreduction of the electrical signals and the maintenance of data bits atmemory locations in a memory system to thereby reconfigure or otherwisealter the CPU's operation, as well as other processing of signals. Thememory locations where data bits are maintained are physical locationsthat have particular electrical, magnetic, optical, or organicproperties corresponding to or representative of the data bits. Itshould be understood that the exemplary embodiments are not limited tothe above-mentioned platforms or CPUs and that other platforms and CPUsmay support the described methods.

The data bits may also be maintained on a computer readable mediumincluding magnetic disks, optical disks, and any other volatile (e.g.,Random Access Memory (“RAM”)) or non-volatile (e.g., Read-Only Memory(“ROM”)) mass storage system readable by the CPU. The computer readablemedium may include cooperating or interconnected computer readablemedium, which exist exclusively on the processing system or aredistributed among multiple interconnected processing systems that may belocal or remote to the processing system. It should be understood thatthe exemplary embodiments are not limited to the above-mentionedmemories and that other platforms and memories may support the describedmethods.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to theinvention unless explicitly described as such. Also, as used herein,each of the articles “a” and “an” are intended to include one or moreitems. Where only one item is intended, the terms “a single” or similarlanguage is used. Further, the terms “any of” followed by a listing of aplurality of items and/or a plurality of categories of items, as usedherein, are intended to include “any of,” “any combination of,” “anymultiple of” and/or “any combination of multiples of” the items and/orthe categories of items, individually or in conjunction with other itemsand/or other categories of items. Further, as used herein, the term“set” is intended to include any number of items, including zero.Further, as used herein, the term “number” is intended to include anynumber, including zero.

Moreover, the claims should not be read as limited to the describedorder or elements unless stated to that effect. In addition, use of theterm “means” in any claim is intended to invoke 35 U.S.C. §112, ¶6, andany claim without the word “means” is not so intended.

What is claimed is:
 1. A method comprising: selecting, from a packetdata network (“PDN”) connection formed through a plurality of accesssystems of a network communicatively coupled with a wireless transmitand/or receive unit, an access system over which to transport a flow ofinternet protocol (“IP”) traffic to, from or to and from the WTRU; andsending, to the WTRU, a request to associate the flow of IP traffic withthe selected access system.
 2. The method of claim 1, wherein selectingan access system comprises selecting the access system responsive to anevent.
 3. The method of claim 2, wherein sending a request to associatethe flow of IP traffic with the selected access system comprises sendingthe request responsive to an event.
 4. The method of claim 2, whereinthe event comprises a condition associated with any of the network andPDN connection.
 5. The method of claim 2, further comprising monitoringthe network for the event.
 6. The method of claim 1, further comprising:awaiting a response to the request sent to the WTRU; receiving, from theWTRU, a second request to associate the flow of IP traffic with a secondaccess system of the plurality of access systems; and responsive to apriority associated with the first request being subordinate to apriority associated with the second request, sending, to the WTRU, anacceptance of the second request.
 7. The method of claim 1, furthercomprising: awaiting a response to the request sent to the WTRU;receiving, from the WTRU, a second request to modify the first request;sending, to the WTRU, a third request comprising a modification to thefirst request; and receiving, in responsive to the third request, anacceptance of the third request.
 8. The method of claim 7, wherein thesecond request and the modification to the first request comprises arequest to associate the flow of IP traffic with a second access systemof the plurality of access systems.
 9. The method of claim 1, furthercomprising: obtaining, at a network entity of the network prior tosending the request, a token whose possession is required to send therequest to associate to the WTRU.
 10. The method of claim 1, furthercomprising: selecting, from the PDN connection, a second access systemover which to transport a sub-flow of the flow of IP traffic to, from orto and from the WTRU; and sending, to the WTRU, a second request to (i)associate the sub-flow with the second selected access system the secondcare-of address and (ii) de-associate such sub-flow from the firstselected access system.
 11. The method of claim 10, further comprisingsending, to the WTRU, information for reordering of packets tofacilitate reconstruction of the flow of traffic.
 12. A method forperforming bandwidth management (“BWM”) in a network comprising firstand second access systems configured in accordance with first and secondaccess technologies, respectively, the method comprising: establishing alocal internet protocol (“IP”) connection via an access node of thefirst access system; establishing a direct tunnel between the accessnode and a local gateway (“LGW”) of the first access system; andestablishing an IP connection between the LGW and a gateway of a mobilecore network (“MCN”).
 13. The method of claim 13, wherein establishingthe local IP connection comprises establishing a first wireless linkwith a wireless transmit/receive unit (“WTRU”), and the method furthercomprises: registering the WTRU with a local home agent (“L-HA”) of thenetwork in connection with the local IP connection; establishing asecond wireless link with a access node of the second access system;adding the second wireless link to the L-HA; and managing the first andsecond wireless links in connection with transport of traffic via theL-HA.
 14. A system for performing bandwidth management (“BWM”) in anetwork comprising first and second access systems configured inaccordance with first and second access technologies, respectively, thesystem comprising: a wireless transmit/receive unit (“WTRU”) comprisinga BWM application; a first access node of the first access system; asecond access node of the second access system; a local gateway (“LGW”)of the network; a direct tunnel established between the second accessnode and the LGW; a local Internet protocol (“IP”) connectionestablished via the first access node and the second access node; afirst wireless link between the WTRU and the first access node; a secondwireless link between the WTRU and the second access node; an IPconnection established between the LGW and a gateway of a mobile corenetwork (MCN); and a local home agent (“L-HA”) of the network adapted to(i) register the WTRU therewith in connection with the local IPconnection, and (ii) manage first and second wireless links.
 15. Thesystem of claim 14, further comprising: a local WLAN access gateway(“WAG”) in communication with the second access node and the L-HA.